February 28, 2011

tree search algorithms

// Breadth-First Search
// The tricky part is that we have to know the entire info. about
// the graph, which indicates in the link-matrix graphmatrix

struct node{
    int color;    // 0-white, 1-grey, 2-black
    int index;    // fount order
    int d;         // distance to the root
    struct node *parent;
};
typedef struct node* Node;

void buildBFS1(int *graphmatrix, Node graph, Node start){
    int i=0, n, head, tail;
    Node queue;    // used as stack to do BFS
    Node temp;

    while(graph[i]!=NULL){
        graph[i].color = 0;
        graph[i].index = i;
        graph[i].parent = NULL;
        graph[i].d = 0;
        i++;
    }
    n = i;
    start->color = 1;
    queue = (Node)malloc(n*sizeof(Node));    // not sure here...
    head = tail = 0;
    enqueue(queue, &tail, start);

    while(!isEmpty(head, tail)){
        temp = dequeue(queue, &head);
        for (i=0; i
            if(graphMatrix[temp->index][i]!=0){
                if(graph[i].color==0){
                    graph[i].color = 1;
                    graph[i].d = temp->d+1;
                    graph[i].parent = temp;
                    enqueue(queue, &tail, graph[i]);
                }
            }
        }
        temp->color = 2;
    }
}

void initQueue(int *head, int *tail){
    *head = *tail =0;
}

void enqueue(Node q, int *tail, Node element){
    q[(*tail)++]=element;
}

Node dequeue(Node q, int *head){
    return q[(*head)++];
}

int isEmpty(int head, int tail){
    return head==tail? 1:0;
}

int isFull(int tail, const int size){
    return tail==size? 1:0;
}


// Depth-First Search
// has more knowledge about the structure of the tree
// at the cost of a more complicated struct

struct node{
    int index;
    int color;
    int detected;
    int finished;
    struct node *parent;
}
typedef struct node* Node;

// the original algorithm in the textbook is a little bit wierd
// cause it is different from BFS by no need of starting point
// while it is obvious that starting with different points will
// generate trees with different structures, given the same link-matrix
void buildDFS(int *graphMatrx, Node graph, Node start){
    int i=0, n, time;
    Node temp;
    while(graph[i]!=NULL){
        graph[i].color = 0;
        graph[i].parent = NULL;
        graph[i].detected = graph[i].finished = 0;
        graph[i].index = i;
        i++;
    }
    n = i;
    time = 0;
    graph[1] = temp;
    graph[1] = start;
    start = temp;    // just want to start at the beginning of the array
    while(i>=0){
        if(graph[i].color == 0)
            visitDFS(graphMatrix, graph, i, &time, n);
        i--;
    }
}

void visitDFS(int *graphMatrix, Node graph, int i, int *time, int length){
    graph[i].color = 1;    // grey, begin to visit
    graph[i].detected = ++(*time);
    for (int j=0; j
        if(graphMatrix[graph[i].index][j]!=0){
            if(graph[j].color == 0){
                graph[j].parent = &graph[i];
                visitDFS(graphMatrix, graph, j, time, length);
            }
        }
    }
    graph[i].color = 2;    // black, conclude the visiting
    graph[i].finished = ++(*time);
}


(to be continued)        
=========

reference: <Introduction to algorithms>

February 21, 2011

some abstract

说到Unix为我们所带来的软件开发的哲学,我必需要说一说。Unix遵循的原则是KISS(Keep it simple, stupid)。在http://en.wikipedia.org/wiki/Unix_philosophy 上有很多的基本上大同小异的Unix哲学,都是很经典的。

Doug McIlroy 是认为UNIX的哲学是这样的:三条哲学,简明扼要,就是这三条哲学贯穿着整个Unix世界。尤其是第一条“do one thing and do it well”真是相当精彩!

    * Write programs that do one thing and do it well.
    * Write programs to work together.
    * Write programs to handle text streams, because that is a universal interface.

只要是Unix的程序员,他们会比别的程序员在任何时候都会不停地强调着这三条哲学。

而《The Art of Unix Programming》总结了下面这些哲学,都是至理名言啊。

    * Rule of Modularity: Write simple parts connected by clean interfaces.
    * Rule of Clarity: Clarity is better than cleverness.
    * Rule of Composition: Design programs to be connected to other programs.
    * Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
    * Rule of Simplicity: Design for simplicity; add complexity only where you must.
    * Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
    * Rule of Transparency: Design for visibility to make inspection and debugging easier.
    * Rule of Robustness: Robustness is the child of transparency and simplicity.
    * Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
    * Rule of Least Surprise: In interface design, always do the least surprising thing.
    * Rule of Silence: When a program has nothing surprising to say, it should say nothing.
    * Rule of Repair: When you must fail, fail noisily and as soon as possible.
    * Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
    * Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
    * Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
    * Rule of Diversity: Distrust all claims for “one true way”.
    * Rule of Extensibility: Design for the future, because it will be here sooner than you think.

X Windows 的设计者 Mike Gancarz 给出了下面九条哲学思想

   1. Small is beautiful.
   2. Make each program do one thing well.
   3. Build a prototype as soon as possible.
   4. Choose portability over efficiency.
   5. Store data in flat text files.
   6. Use software leverage to your advantage.
   7. Use shell scripts to increase leverage and portability.
   8. Avoid captive user interfaces.
   9. Make every program a filter.


十条不错的编程观点
1) The only “best practice” you should be using all the time is “Use Your Brain”, rather than some so-called "famous" frameworks, methods, classes, or prototypes.
2)Programmers who don’t code in their spare time for fun will never become as good as those that do.
3)Most comments in code are in fact a pernicious form of code duplication, which should explain "why", rather than "how" and "what".
4)XML is highly overrated
5)Not all programmers are created equal
6)”Googling it” is okay!
7)If you only know one language, no matter how well you know it, you’re not a great programmer.
8)Your job is to put yourself out of work. Or, saying, if you can’t be replaced then you can’t be promoted!
9)Design patterns are hurting good design more than they’re helping it.
10)Unit Testing won’t help you write good code

Days of our lives

Daisypath Anniversary tickers