Every bus in the Ekaterinburg city has a special man (or woman) called conductor. When you ride the bus, you have to give money to the conductor. We know that there are more then P% conductors and less then Q% conductors. Your task is to determine a minimal possible number of Ekaterinburg citizens.

 1 #include <iostream>
 2 #include <cmath>
 3 
 4 using namespace std;
 5 
 6 int main()
 7 {
 8     double dp, dq;
 9     cin >> dp >> dq;
10     int p = floor(dp * 100 + 0.5);
11     int q = floor(dq * 100 + 0.5);
12     for (int i = 1; ; i++) {
13         int a = p * i / 10000;
14         int b = q * i / 10000;
15         if ((a < b) && (q * i % 10000 > 0)) {
16             cout << i << endl;
17             return 0;
18         }
19     }
20     return 0;
21 }
22 

这里我想针对样章上的一个问题谈谈自己的理解。

问题很简单，求二进制中1的个数。对于一个字节（8bit）的变量，求其二进制表示中"1"的个数，要求算法的执行效率尽可能的高。

先来看看样章上给出的几个算法：

解法一，每次除二，看是否为奇数，是的话就累计加一，最后这个结果就是二进制表示中1的个数。

解法二，同样用到一个循环，只是里面的操作用位移操作简化了。

   1:  int Count(int v)  
   2:  {  
   3:      int num = 0;
   4:      while (v) {  
   5:          num += v & 0x01;  
   6:          v >>= 1;  
   7:      }  
   8:      return num;  
   9:  }

解法三，用到一个巧妙的与操作，v & (v -1 )每次能消去二进制表示中最后一位1，利用这个技巧可以减少一定的循环次数。

解法四，查表法，因为只有数据8bit，直接建一张表，包含各个数中1的个数，然后查表就行。复杂度O(1)。

   1:  int countTable[256] = { 0, 1, 1, 2, 1, ..., 7, 7, 8 };  
   2:     
   3:  int Count(int v) {  
   4:      return countTable[v];  
   5:  }
  
好了，这就是样章上给出的四种方案，下面谈谈我的看法。

首先是对算法的衡量上，复杂度真的是唯一的标准吗？尤其对于这种数据规模给定，而且很小的情况下，复杂度其实是个比较次要的因素。

查表法的复杂度为O(1)，我用解法一，循环八次固定，复杂度也是O(1)。至于数据规模变大，变成32位整型，那查表法自然也不合适了。

其次，我觉得既然是这样一个很小的操作，衡量的尺度也必然要小，CPU时钟周期可以作为一个参考。

解法一里有若干次整数加法，若干次整数除法（一般的编译器都能把它优化成位移），还有几个循环分支判断，几个奇偶性判断（这个比较耗时间，根据CSAPP上的数据，一般一个branch penalty得耗掉14个左右的cycle），加起来大概几十个cycle吧。

再看解法四，查表法看似一次地址计算就能解决，但实际上这里用到一个访存操作，而且第一次访存的时候很有可能那个数组不在cache里，这样一个cache miss导致的后果可能就是耗去几十甚至上百个cycle（因为要访问内存）。所以对于这种“小操作”，这个算法的性能其实是很差的。

这里我再推荐几个解决这个问题的算法，以32位无符号整型为例。

   1:  int Count(unsigned x) {  
   2:     x = x - ((x >> 1) & 0x55555555);   
   3:     x = (x & 0x33333333) + ((x >> 2) & 0x33333333);   
   4:     x = (x + (x >> 4)) & 0x0F0F0F0F;   
   5:     x = x + (x >> 8);   
   6:     x = x + (x >> 16);   
   7:     return x & 0x0000003F;   
   8:  }
  
这里用的是二分法，两两一组相加，之后四个四个一组相加，接着八个八个，最后就得到各位之和了。

还有一个更巧妙的HAKMEM算法

   1:  int Count(unsigned x) {
   2:     unsigned n;   
   3:     
   4:     n = (x >> 1) & 033333333333;   
   5:     x = x - n;  
   6:     n = (n >> 1) & 033333333333;  
   7:     x = x - n;   
   8:     x = (x + (x >> 3)) & 030707070707;  
   9:     x = modu(x, 63); 
   10:     return x;  
   11:  }
  
首先是将二进制各位三个一组，求出每组中1的个数，然后相邻两组归并，得到六个一组的1的个数，最后很巧妙的用除63取余得到了结果。

因为2^6 = 64，也就是说 x_0 + x_1 * 64 + x_2 * 64 * 64 = x_0 + x_1 + x_2 (mod 63)，这里的等号表示同余。

这个程序只需要十条左右指令，而且不访存，速度很快。

由此可见，衡量一个算法实际效果不单要看复杂度，还要结合其他情况具体分析。

关于后面的两道扩展问题，问题一是问32位整型如何处理，这个上面已经讲了。

问题二是给定两个整数A和B，问A和B有多少位是不同的。

这个问题其实就是数1问题多了一个步骤，只要先算出A和B的异或结果，然后求这个值中1的个数就行了。

总体看来这本书还是很不错的，比较喜欢里面针对一个问题提出不同算法并不断改进的风格。这里提出一点个人的理解，望大家指正 ;-)

(by ZelluX   http://www.blogjava.net/zellux)

(define (reverse items)
  (define (reverse-iter i k)
    (if (null? i)
        k
        (reverse-iter (cdr i)
                      (cons (car i) k))))
 
  (reverse-iter items ()))

(define (filter predicate sequence)
  (cond ((null? sequence) null)
        ((predicate (car sequence))
         (cons (car sequence) 
               (filter predicate (cdr sequence))))
        (else (filter predicate (cdr sequence)))))

(define (accumulate op initial sequence)
  (if (null? sequence)
      initial
      (op (car sequence)
          (accumulate op initial (cdr sequence)))))

(define (enumerate-interval low high)
  (if (> low high)
      null
      (cons low (enumerate-interval (+ low 1) high))))

(define (enumerate-tree tree)
  (cond ((null? tree) null)
        ((pair? tree)
         (append (enumerate-tree (car tree))
                 (enumerate-tree (cdr tree))))
        (else (list tree))))

(define (hornel-eval x coefficient-sequence)
  (accumulate (lambda (this-coeff higher-terms)
                (+ this-coeff (* x higher-terms)))
              0
              coefficient-sequence))

Ex 2.35
数出一棵树中的叶子数。这题我的做法比较土，没想到map-reduce操作上的递归，而是把叶子节点的值都改成1然后一个累加。

(define (count-leave tree)
  (accumulate +
              0
              (map (lambda (x) 1)
                   (enumerate-tree tree))))

其实只要递归调用主函数就行了

(define (count-leaves t)
  (accumulate + 0 (map (lambda (x) (if (pair? x) (count-leaves x) 1)) t)))

Ex 2.36
可以理解为计算矩阵各列之和吧

(define (accumulate-n op init seqs)
  (if (null? (car seqs))
      null
      (cons (accumulate op init (map car seqs))
            (accumulate-n op init (map cdr seqs)))))

NFA构造O(n)，匹配O(nm)
DFA构造O(2^n)，最小化O(kn'logn')（N'=O(2^n)），匹配O(m)
n=regex长度，m=串长，k=字母表大小，n'=原始的dfa大小
大概是这样子吧

I normally do not read comp.lang.c, but Jim McKie told me that ``Duff's device'' had come up in comp.lang.c again.  I have lost the version that was sent to netnews in May 1984, but I have reproduced below the note in which I originally proposed the device.  (If anybody has a copy of the netnews version, I would gratefully receive a copy at research!td or td@research.att.com.)

To clear up a few points:

1. The point of the device is to express general loop unrolling directly in C.  People who have posted saying `just use memcpy' have missed the point, as have those who have criticized it using various machine-dependent memcpy implementations as support.  In fact, the example in the message is not implementable as memcpy, nor is any computer likely to have an memcpy-like idiom that implements it.

    

2. Somebody claimed that while the device was named for me, I probably didn't invent it.  I almost certainly did invent it.  I had definitely not seen or heard of it when I came upon it, and nobody has ever even claimed prior knowledge, let alone provided dates and times.  Note the headers on the message below:  apparently I invented the device on November 9, 1983, and was proud (or disgusted) enough to send mail to dmr.  Please note that I do not claim to have invented loop unrolling, merely this particular expression of it in C.

    

3. The device is legal dpANS C.  I cannot quote chapter and verse, but Larry Rosler, who was chairman of the language subcommittee (I think), has assured me that X3J11 considered it carefully and decided that it was legal. Somewhere I have a note from dmr certifying that all the compilers that he believes in accept it.  Of course, the device is also legal C++, since Bjarne uses it in his book.

    

4. Somebody invoked (or more properly, banished) the `false god of efficiency.'  Careful reading of my original note will put this slur to rest.  The alternative to genuflecting before the god of code-bumming is finding a better algorithm.  It should be clear that none such was available.  If your code is too slow, you must make it faster.  If no better algorithm is available, you must trim cycles.

    

5. The same person claimed that the device wouldn't exhibit the desired speed-up.  The argument was flawed in two regards:  first, it didn't address the performance of the device, but rather the performance of one of its few uses (implementing memcpy) for which many machines have a high-performance idiom.  Second, the poster made his claims in the absence of timing data, which renders his assertion suspect.  A second poster tried the test, but botched the implementation, proving only that with diligence it is possible to make anything run slowly.

    

6. Even Henry Spencer, who hit every other nail square on the end with the flat round thing stuck to it, made a mistake (albeit a trivial one).  Here is Henry replying to bill@proxftl.UUCP (T. William Wells):
   

      >>... Dollars to doughnuts this
       >>was written on a RISC machine.
       >Nope.  Bell Labs Research uses VAXen and 68Ks, mostly.
       

   I was at Lucasfilm when I invented the device.

    

7. Transformations like this can only be justified by measuring the resulting code.  Be careful when you use this thing that you don't unwind the loop so much that you overflow your machine's instruction cache.  Don't try to be smarter than an over-clever C compiler that recognizes loops that implement block move or block clear and compiles them into machine idioms.

Here then, is the original document describing Duff's device:

From research!ucbvax!dagobah!td  Sun Nov 13 07:35:46 1983
Received: by ucbvax.ARPA (4.16/4.13)  id AA18997; Sun, 13 Nov 83 07:35:46 pst
Received: by dagobah.LFL (4.6/4.6b)  id AA01034; Thu, 10 Nov 83 17:57:56 PST
Date: Thu, 10 Nov 83 17:57:56 PST
From: ucbvax!dagobah!td (Tom Duff)
Message-Id: <8311110157.AA01034@dagobah.LFL>
To: ucbvax!decvax!hcr!rrg, ucbvax!ihnp4!hcr!rrg, ucbvax!research!dmr, ucbvax!research!rob

Consider the following routine, abstracted from code which copies an array of shorts into the Programmed IO data register of an Evans & Sutherland Picture System II:

 
send(to, from, count)

register short *to, *from;

register count;

{

    do

        *to = *from++;

    while (--count>0);

}

(Obviously, this fails if the count is zero.)
The VAX C compiler compiles the loop into 2 instructions (a movw and a sobleq,
I think.)  As it turns out, this loop was the bottleneck in a real-time animation playback program which ran too slowly by about 50%.  The standard way to get more speed out of something like this is to unwind the loop a few times, decreasing the number of sobleqs.  When you do that, you wind up with a leftover partial loop.  I usually handle this in C with a switch that indexes a list of copies of the original loop body.  Of course, if I were writing assembly language code, I'd just jump into the middle of the unwound loop to deal with the leftovers.  Thinking about this yesterday, the following implementation occurred to me:

send(to, from, count)
    register short *to, *from;
    register count;
{
    register n=(count+7)/8;
    switch(count%8) {
        case 0:    do {    *to = *from++;
        case 7:        *to = *from++;
        case 6:        *to = *from++;
        case 5:        *to = *from++;
        case 4:        *to = *from++;
        case 3:        *to = *from++;
        case 2:        *to = *from++;
        case 1:        *to = *from++;
        } while(--n>0);
    }
}

It amazes me that after 10 years of writing C there are still little corners that I haven't explored fully.  (Actually, I have another revolting way to use switches to implement interrupt driven state machines but it's too horrid to go into.)

Many people (even bwk?) have said that the worst feature of C is that switches don't break automatically before each case label.  This code forms some sort of argument in that debate, but I'm not sure whether it's for or against.

yrs trly
Tom

线索二叉树

当用二叉链表作为二叉树的存储结构时，因为每个结点中只有指向其左、右儿子结点的指针，所以从任一结点出发只能直接找到该结点的左、右儿子。在一般情况下靠它无法直接找到该结点在某种遍历序下的前驱和后继结点。如果在每个结点中增加指向其前驱和后继结点的指针，将降低存储空间的效率。

我们可以证明：在n个结点的二叉链表中含有n+1个空指针。因为含n个结点的二叉链表中含有个指针，除了根结点，每个结点都有一个从父结点指向该结点的指针，因此一共使用了n-1个指针，所以在n个结点的二叉链表中含有n+1个空指针。

因此可以利用这些空指针，存放指向结点在某种遍历次序下的前驱和后继结点的指针。这种附加的指针称为线索，加上了线索的二叉链表称为线索链表，相应的二叉树称为线索二叉树。为了区分一个结点的指针是指向其儿子的指针，还是指向其前驱或后继结点的线索，可在每个结点中增加两个线索标志。这样，线索二叉树结点类型定义为：

其中ltag为左线索标志，rtag为右线索标志。它们的含义是:

• ltag=0，LeftChild是指向结点左儿子的指针；
• ltag=1，LeftChild是指向结点前驱的左线索。
  
• rtag=0，RightChild是指向结点右儿子的指针；
• rtag=1，RihgtChild是指向结点后继的右线索。

例如图13(a)是一棵中序线索二叉树，它的线索链表如图13(b)所示。

(a)

(b)

图13 线索二叉树及其线索链表

图13(b)中，在二叉树的线索链表上增加了一个头结点，其LeftChild指针指向二叉树的根结点，其RightChild指针指向中序遍历时的最后一个结点。另外，二叉树中依中序列表的第一个结点的LeftChild指针，和最后一个结点的RightChild指针都指向头结点。这就像为二叉树建立了一个双向线索链表，既可从第一个结点起，顺着后继进行遍历，也可从最后一个结点起顺着前驱进行遍历。

如何在线索二叉树中找结点的前驱和后继结点？以图13的中序线索二叉树为例。树中所有叶结点的右链是线索，因此叶结点的RightChild指向该结点的后继结点，如图13中结点"b"的后继为结点"*"。当一个内部结点右线索标志为0时，其RightChild指针指向其右儿子，因此无法由RightChild得到其后继结点。然而，由中序遍历的定义可知，该结点的后继应是遍历其右子树时访问的第一个结点，即右子树中最左下的结点。例如在找结点"*"的后继时，首先沿右指针找到其右子树的根结点"-"，然后沿其LeftChild指针往下直至其左线索标志为1的结点，即为其后继结点(在图中是结点"c")。类似地，在中序线索树中找结点的前驱结点的规律是：若该结点的左线索标志为1，则LeftChild为线索，直接指向其前驱结点，否则遍历左子树时最后访问的那个结点，即左子树中最右下的结点为其前驱结点。由此可知，若线索二叉树的高度为h，则在最坏情况下，可在O(h)时间内找到一个结点的前驱或后继结点。在对中序线索二叉树进行遍历时，无须像非线索树的遍历那样，利用递归引入栈来保存待访问的子树信息。

对一棵非线索二叉树以某种次序遍历使其变为一棵线索二叉树的过程称为二叉树的线索化。由于线索化的实质是将二叉链表中的空指针改为指向结点前驱或后继的线索，而一个结点的前驱或后继结点的信息只有在遍历时才能得到，因此线索化的过程即为在遍历过程中修改空指针的过程。为了记下遍历过程中访问结点的先后次序，可附设一个指针pre始终指向刚刚访问过的结点。当指针p指向当前访问的结点时，pre指向它的前驱。由此也可推知pre所指结点的后继为p所指的当前结点。这样就可在遍历过程中将二叉树线索化。对于找前驱和后继结点这二种运算而言，线索树优于非线索树。但线索树也有其缺点。在进行插人和删除操作时，线索树比非线索树的时间开销大。原因在于在线索树中进行插人和删除时，除了修改相应的指针外，还要修改相应的线索。

另外我有这次比赛的测试数据和标程，需要的朋友留言即可。

#include <iostream>
#include <fstream>
#include <vector>
#include <queue>

using namespace std;

class node {
public: 
    int first, second;

    node(int x, int y)
    {
        first = x;
        second = y;
    }

    bool operator< (const node &rhs) const
    {
        if (second < rhs.second) 
            return true;
        else if (second > rhs.second)
            return false;
        else return (first > rhs.first);
    }
};


int main()
{
    int n, h;
    int d[26], t[26], f[26];
    priority_queue<node, vector<node>, less<vector<node>::value_type> > heap;
    vector<int> best(26);
    cin >> n;
    while (true) {
        if (n == 0) break;
        cin >> h;
        for (int i = 1; i <= n; i++)
            cin >> f[i];

        for (int i = 1; i <= n; i++)
            cin >> d[i];

        t[0] = 0;
        for (int i = 1; i < n; i++)
            cin >> t[i];

        best.clear();
        int max = -1;
        // i indicates the last lake
        for (int i = 1; i <= n; i++) {
            vector<int> tempBest(26);
            int valueGet = 0;
            
            int timeLeft = h * 12;
            for (int j = 1; j <= i; j++)
                timeLeft -=    t[j - 1];

            if (timeLeft <= 0) break;
            while (!heap.empty())
                heap.pop();

            for (int j = 1; j <= i; j++)
                heap.push(node(j, f[j]));

            while ((!heap.empty()) && (timeLeft > 0)) {
                int next = heap.top().first;
                if (heap.top().second > 0) {
                    timeLeft--;
                    tempBest[next]++;
                    valueGet += heap.top().second;
                }
                int valueLeft = heap.top().second - d[next];
                heap.pop();
                if (valueLeft > 0)
                    heap.push(node(next, valueLeft));
            }
            if (valueGet > max) {
                max = valueGet;
                best = tempBest;
                if (timeLeft > 0)
                    best[1] += timeLeft;
            }
        }