[
2006/03/12 22:18 | by turbozv ]
2006/03/12 22:18 | by turbozv ]
之所以用这个标题是因为看到了PC上一款比较pop的软件: 雪狐桌面精灵（Desktop Sprite）。界面非常华丽，有40余款漂亮的皮肤，支持天气预报，让人耳目一新
不过，看到他的介绍：“支持公元1年～9999年的真正万年历”，让我非常怀疑。
经过测试，发现他的不少历法数据是错误的……说实话，对于软件来说，准确性是最重要的。
经过一定的分析，我发现在历法数据的整理分类和推算上，掌心万年历都强过它。不过由于掌心万年历现在的PC版本过于简陋，所以还无法和雪狐抗衡。但是…… 我有信心写一款完全超越它的掌心万年历For PC版本出来。
嘿嘿…… 一切等论文结束以后再说啦～
不过，看到他的介绍：“支持公元1年～9999年的真正万年历”，让我非常怀疑。
经过测试，发现他的不少历法数据是错误的……说实话，对于软件来说，准确性是最重要的。
经过一定的分析，我发现在历法数据的整理分类和推算上，掌心万年历都强过它。不过由于掌心万年历现在的PC版本过于简陋，所以还无法和雪狐抗衡。但是…… 我有信心写一款完全超越它的掌心万年历For PC版本出来。
嘿嘿…… 一切等论文结束以后再说啦～
[ 2006/02/26 10:31 | by turbozv ]
2006/02/26 10:31 | by turbozv ]
今天晚上把掌心万年历的内部数据全部做成Unicode，其他地方轻松搞定，不过就是在节日文件festivals.txt上出了不小的问题。
【问题一】在Active Sync软件中将PC上的unicode格式的festivals.txt拷贝到PPC后，被默认地转换为ascii格式
【解决办法】我忍了，改为festivals.dat，这下Active Sync不加转换了
【问题二】Unicode文件格式的识别
【解决办法】头部两个字节 0xff, 0xfe，在写程序的时候注意了一下 fread(buf, 2, 1, fp); 之后是用强制转换来解决无符号数和有符号数的比较问题
if (0xff != (unsigned char)buf［0］ && 0xfe != (unsigned char)buf［1］) { //ERROR }
【问题三】Unicode文件的读入，fgetws()不能读正确读入Unicode
【解决办法】这个问题我拿到VC6下面去试了一把，结果正确，但是eVC4就是不对。没办法，自己做解码吧，先读取0xff, 0xfe, 然后顺序读ch1, ch2，把ch1 + ch2 << 8 赋值给一个wch，如此反复。
【问题四】Unicode文件的写回
【解决办法】和上面一个类型的问题，MSDN上也没说太明白，fwprintf()写回的内容仍然是ASCII格式。我觉得很奇怪，难道M$的fwprintf在写入文件的时候自行做了一次wcstombs的转码？不管了，自己再做了一次同上的代码。faint！
【问题一】在Active Sync软件中将PC上的unicode格式的festivals.txt拷贝到PPC后，被默认地转换为ascii格式
【解决办法】我忍了，改为festivals.dat，这下Active Sync不加转换了
【问题二】Unicode文件格式的识别
【解决办法】头部两个字节 0xff, 0xfe，在写程序的时候注意了一下 fread(buf, 2, 1, fp); 之后是用强制转换来解决无符号数和有符号数的比较问题
if (0xff != (unsigned char)buf［0］ && 0xfe != (unsigned char)buf［1］) { //ERROR }
【问题三】Unicode文件的读入，fgetws()不能读正确读入Unicode
【解决办法】这个问题我拿到VC6下面去试了一把，结果正确，但是eVC4就是不对。没办法，自己做解码吧，先读取0xff, 0xfe, 然后顺序读ch1, ch2，把ch1 + ch2 << 8 赋值给一个wch，如此反复。
【问题四】Unicode文件的写回
【解决办法】和上面一个类型的问题，MSDN上也没说太明白，fwprintf()写回的内容仍然是ASCII格式。我觉得很奇怪，难道M$的fwprintf在写入文件的时候自行做了一次wcstombs的转码？不管了，自己再做了一次同上的代码。faint！
[ 2006/02/20 08:23 | by turbozv ]
2006/02/20 08:23 | by turbozv ]
最近几天都在思考重构 历史上的今天。
总体来说，这个问题需要处理的1万条左右的文本，总长度有10MB左右，很自然我们需要对数据做一个索引。对于这个具体的问题，我们需要的索引数据是{发生时间+事件标题+内容偏移量+内容长度}，但是这里有一个问题，采用定长的索引，势必标题这个变长的数据不好处理，会浪费不少的磁盘空间和内存空间。但是如果采用变长的索引，在读取的时候会带来繁琐和低效。最终我采用的是定长的索引，不过额外引入了一个标题池，即：每条索引={发生事件+标题偏移量+内容偏移量+内容长度}，索引文件分位三部分：{记录条数n+n条定长的索引+标题池}，那么我们读取的时候就非常简单了：
1)读取记录条数n
2)分配n条索引的空间给，从文件中直接读入n条索引
3)分配标题池，空间=文件长度-当前文件位置，从文件中直接读入标题池
对于索引的生成，需要分两步，第一步写{记录条数n + n条定长索引}，注意索引在写入的时候，动态计算它的标题偏移量；第二步写标题池，直接遍历一次写入。
在PPC上的运行结果非常令人满意，不过这个索引跑得还真是够慢，哈哈，当然瓶颈是在于磁盘读写：）
总体来说，这个问题需要处理的1万条左右的文本，总长度有10MB左右，很自然我们需要对数据做一个索引。对于这个具体的问题，我们需要的索引数据是{发生时间+事件标题+内容偏移量+内容长度}，但是这里有一个问题，采用定长的索引，势必标题这个变长的数据不好处理，会浪费不少的磁盘空间和内存空间。但是如果采用变长的索引，在读取的时候会带来繁琐和低效。最终我采用的是定长的索引，不过额外引入了一个标题池，即：每条索引={发生事件+标题偏移量+内容偏移量+内容长度}，索引文件分位三部分：{记录条数n+n条定长的索引+标题池}，那么我们读取的时候就非常简单了：
1)读取记录条数n
2)分配n条索引的空间给，从文件中直接读入n条索引
3)分配标题池，空间=文件长度-当前文件位置，从文件中直接读入标题池
对于索引的生成，需要分两步，第一步写{记录条数n + n条定长索引}，注意索引在写入的时候，动态计算它的标题偏移量；第二步写标题池，直接遍历一次写入。
在PPC上的运行结果非常令人满意，不过这个索引跑得还真是够慢，哈哈，当然瓶颈是在于磁盘读写：）
[ 2006/02/13 07:50 | by turbozv ]
2006/02/13 07:50 | by turbozv ]
Windows自带游戏中的Freecell是Chris三年来一直很想解的一个游戏，今天晚饭后再次和我们聊起这个话题，于是我们打算回家试试。
我对Freecell这个游戏不熟悉（I prefer Solitaire ;)），看了一下游戏规则，暂时没有什么致胜策略。
现看看直接枚举的复杂度吧，
1)移动到回收区域[12]
2)在下面8列中移动[C(8,2)]
3)移动到临时区域[8]
4)临时区域移动到下面8列[4]
一层有12+32+8+4=56种移动方法。
感觉直接来BFS/DFS都不是太好的办法，于是在网上搜罗一番，终于发现强者：
Freecell Solver ( http://vipe.technion.ac.il/~shlomif/freecell-solver )
我对Freecell这个游戏不熟悉（I prefer Solitaire ;)），看了一下游戏规则，暂时没有什么致胜策略。
现看看直接枚举的复杂度吧，
1)移动到回收区域[12]
2)在下面8列中移动[C(8,2)]
3)移动到临时区域[8]
4)临时区域移动到下面8列[4]
一层有12+32+8+4=56种移动方法。
感觉直接来BFS/DFS都不是太好的办法，于是在网上搜罗一番，终于发现强者：
Freecell Solver ( http://vipe.technion.ac.il/~shlomif/freecell-solver )
