欢迎参加8月5日哈工大机器学习小组第三次活动－粗糙集概况

主题：粗糙集概况
时间：2006年8月5日（周六），上午8:30~11:30
地点：哈工大动力楼620房间，主楼背后邵馆旁边

报告题目1: 处理混合数据的若干粗糙集模型
主讲人：胡清华
内容简介：Pawlak粗糙集模型基于经典的等价关系和划分进行构造，适合于处理符号型数据。然而现实应用的数据库中，往往保存的是数值型数据或符号型与数值型数据共存。如何处理该类数值型或混合型数据成为近年来粗糙及理论研究的一个热点。本次讲座将综述当前各种解决方案，分析各种方案存在的问题，然后展示近两年作者在此方面进行的一些探索。作者提出了模糊信息熵、邻域模型、模糊邻域和一类改进的模糊粗糙模型解决这一问题，本次讲座将展示各种方法的理论模型、算法设计和试验效果，并且提供程序代码共大家对比分析。

报告题目2:
论文学习：粗糙集理论研究最新进展及发展趋势
主讲人：郎君
内容简介：粗糙集理论是一种较新的软计算方法,是分析和处理不完备信息的一种有效工具。分析了粗糙集理论研究的最新进展,指出了粗糙集理论研究中存在的问题,并对粗糙集理论研究的发展趋势进行了展望。

报告题目3：论文学习：Rough sets, decision algorithms and Bayes' theorem
主讲人：叶玉玲
报告大纲：这篇论文是Pawlak在2000年撰写的文章。阐述了粗糙集，决策算法和贝叶斯理论之间的关系。

报告题目4：论文学习：基于粗糙集的客户细分研究
主讲人：姚平
内容简介：客户细分是根据客户不同的行为特征，将客户区分成不同的客户群体，供企业前台部门以及决策人员实施不同的市场营销手段。基于客户信息的客户细分，被称作为数据驱动的客户细分。本文应用粗糙集理论算法对客户数据表进行了属性约简与规则提取，证明了其有效性。

欢迎大家广泛参与，让交流成为习惯！

希望参加这次活动的同学请在如下wiki中登记一下（便于以后活动联系）。

http://ltp.ir-lab.org/mywiki/moin.cgi/%E7%B2%97%E7%B3%99%E9%9B%86

邀请大家加入哈工大机器学习小组讨论QQ群：27980716

欢迎大家多多光临咱们的机器学习论坛：
http://bbs.ir-lab.org/cgi-bin/forums.cgi?forum=20

再次犯下C++错误

接着昨天的最后一段如下代码，本以为好使了，但后后来又出现了内存泄漏和内存溢出的现象。具体征兆是这样的。刚开始处理小文本的时候只是有内存泄漏的问题，内容占用越来越多。分析发现是代码中申请的动态字符数组没有释放，每次使用都申请一次，久而久之就越来越多了。

string strTemp = "";
strTemp = Processed();
int len = strTemp.size();
char* str = new char[len];
strcpy(str, strTemp.c_str() );
return str;

内存溢出的问题是在今天早上发现了。在处理超长文本的时候，总是出现莫名奇妙的程序崩溃。经过向pineapple请教后，得到的指点是可以用如下一段代码来代替。另外pineapple还指点我说如果把上面的那段代码中第四行修改为static char* str = new char[len]；会出现内存溢出的情况，因为静态字符数组的申请只是在第一次调用的时候进行，后面的调用如果遇到超出第一次len长度的字符串拷贝 strcpy就会出现内存溢出。呵呵，感觉真的好险呀！下面的这段代码中的第一句其实也是一个静态变量，但是这个变量会比较好的解决内存泄漏和内存溢出的问题。下面的这段代码在俺的程序中现在运行正常，但是还需要进行深度的测试。据pineapple说，这种实现方法仍然存在一些问题的。呵呵，明日继续请教啦！

static std::string strTemp;
strTemp = Processed();
return (char*)strTemp.c_str();

谢谢pineapple!

犯下C++低级错误

在完成新版的LTP的Socket访问模式的过程中，有一个结果不稳定的错误一直困扰着我。那就是socket返回的结果不稳定，对于短小文本结果多数时候正确，但是会偶尔出现返回结果开头字符变成乱码的情况；对于长文本几乎都不能正确返回结果。打印即将的返回值到文本文件中，每次查看又都是正确的。采用先存为文件，然后将文件内容读取到char *[]中的方法返回却又能够得到完全正确的结果。呜呜……，这个问题真的很大，一直萦绕在我的头顶，真是吃饭睡觉都在想着这个问题。

真正解决这个问题，是在我不断的缩小查错范围后发现到可能情形的。在偶像陈儒的指点下才恍然大悟，自己犯下了C++中的一种常见的错误：函数返回局部变量的地址。

原先在我的程序中，一个大函数末尾有如下一段代码（大函数返回值类型为 char*）)：

string strTemp = "";
strTemp = Processed(); // 这里Processed()是举例说明，这里返回一个字符串
return (char*)strTemp.c_str();

经过多次的跟踪和调试，我找到了是最后那句return出现了问题。起初我还以为是(char*)strTemp.c_str()对于strTemp的长度有所限制。经过陈儒帮我验证，发现并没有这样的限制。等到我把上面这段代码发送给陈儒，他非常直觉的告诉我可能是返回了一个局部变量的内存地址。这个局部变量的在函数运行结束后会被释放，其内容可能会被其他程序刷新。听到这个，我才恍然大悟，结果的不稳定原因就在这里。对于短字符串，内容被刷新的可能性比较小，而长字符串（比如上M）被刷新的可能性较大，使得程序运行起来出现前面提到的文本越长结果越不稳定的情况。

真是呜呜……，这种错误在C++编程里面是很低级的错误。但是回想自己犯下这种错误的原因，我分析是以前重来没有考虑过领事申请的一个string会去return它的地址，以前的直接return内容从来没有错过的。呵呵，socket模式下要求返回char *[]使得我犯下了下这个错误。不过，还算好，算是经验积累了，以后就不会再犯这样的错误了。

针对上面的代码，我修改为如下代码：

string strTemp = "";
strTemp = Processed();
int len = strTemp.size();
char* str = new char[len];
strcpy(str, strTemp.c_str() );
return str;

这样修改之后程序终于结束了结果不稳定的情况。感谢陈儒！

呵呵，算来自己从2000年学习C语言，2003年进入实验室后开始学习C++，C/C++编程的经验已经有好几年了。但是仔细想想自己现在的C/C++水平真是不怎么样，当初自己学习C++ Primer的时候只是学习了一半，现在看来那后一半有非常大的必要性仔细学习。呵呵，俺会认真的补上这课的。这不，俺刚才又发现随着函数调用次数的增多，程序占用的内存也逐渐增多了。这是程序中有内存泄漏的表现，还需要明天认证诊断呀！

Coder to Develpoer - Nailing Down a Feature Set

How exciting it is! Yesterday, I just post an entry about the book "Coder to developer". This noon, I began to read it. Although I had read only few pages, I had to say that it was heuristic for my mind. When I read the pure English words with some help of KingSoft Ciba, I figured out one viewpoint of the author: there were so many Computer Science department could not actually teach you software development skill, like teamwork. All the students should learn the related skills by themselves. Yeah. To, my own experience, I had not been really taught any software development skills. All the things I should learn by myself. And currently, I am still a beginning learner of software development. In the developing process of LTP, I should keep learning everyday.

How to develop good software not only writing good code? You can take part into some practical project in some software corporation. But to the little experienced students, one good book about it is also good. So now, I believed the book "Coder to developer" was such one.

To software development, as we know the first step is requirement analysis, namely features including. In chapter one: planning your project, the first section is "Nailing Down a Feature Set". I think it is visualized for requirement analysis. And then how to nail down the feature set? There is an advanced and simple technique: The Elevator Pitch. Yeah, maybe you are confused by the new concept. So what is "The Elevator Pitch"?

Suppose you were finding some venture capital for your new and wonderful software idea, and you had prepared enough with a 15 minute presentation about it, you were coming into a big building to ask help of a senior partner. And as usual, he was so busy that he could only talk with you in the 30-second elevator ride. So what should you say to the VC now? You should use very few words to express your new idea. And whether the words can attract the listener's attention is crucial to your software. For example, the author showed us a paragraph about his software Download Tracker, as following:

---

Download Tracker builds a personal catalog of all the software that you download from the Internet. You can add descriptions and keywords to identify each software package. Later on you can edit this information and add your own ratings. With Download Tracker, you’ll never forget where you saved a program again, or lose track of the name of the file that installs your favorite freeware application. If you run a website, you can even use Download Tracker to automatically generate a list of your favorite downloads, complete with hyperlinks.

---

The main points about how to use words are:

---

Short is better than long. A long and rambling elevator pitch probably means you haven’t really decided what you’re building yet.

Functionality trumps technology. Potential customers care about what your software will do. They usually don’t care how your software does it.

Solve a problem. If you can’t explain what problem your application will solve, customers won’t know why they should buy it.

Pitch the benefits, not yourself. Customers won’t be buying you, your superior knowledge, or your development team (if you’re lucky enough to be working with a team). They’ll be buying the software.

Figure out what’s important to your audience, and make sure you address that. Are the people buying your product most interested in cost, innovation, features, compatibility, or something else entirely?

---

Yeah! In my mind, I believed that the Elevator Pitch was just like the summarization of research papers. You should use fewest words to attract the attention of the readers.

There was another point about the feature set: Feature creep—the continuing addition of new functionality while you’re still writing the code—is one of the biggest enemies that keep you from actually finishing a project.

Now, to my project of LTP, I felt little like feature creeping now. So the most important thing was to nail down the feature set of LTP, then I could do the right things.

[Collection]从Coder到Developer

从Coder到Developer

你是否对软件开发已经了如指掌？如果是，那么就请别往下读了。
Coder(编码人员)与Developer(开发人员)的区别是什么？Coder是指那些熟练掌握了某门计算机语言的人。而Developer是指那些人，能拿起需求或概念来，组成一支团队，应用现代开发过程，做出合乎需求的设计，然后制造出来高质量的产品来。

Mike Gunderloy在他的新书《Coder To Developer -- Tools and Strategies for Delivering Your Software》里告诉我们，想成为一个合格的软件开发人员，应该掌握什么东西。

在该书的15章里，Mike Gunderloy以一个.NET程序开发为例，深入浅出地谈及了软件开发中的方方面面，从计划，组织，应用源码控制，防卫性编程，使用单元测试，熟练掌握和武装IDE，深入理解/重用代码，使用工具生成编码，缺陷追踪，记录程序行为，团队合作，产生文档，精通运行代码的生成过程，保护知识产权，到交付与产品的安装/部署，在每个方面都提出了非常可借鉴的看法和经验。

譬如，在第三章《Using Source Code Control Effectively(有效地使用源码控制)》里，他谈及源码控制里的三个层次，现有市面上的种种源码控制工具，如何据于需求(价格，开发风格，代码repository，网络友好性，与IDE的集成，所需高级指令，跨平台支持等等)做出选择。

在第五章《Pumping Up the IDE(如何武装IDE)》里，他谈及怎么用户化IDE，设置有用选项，使用VS.Net PowerToys，编写Macros，选择Add-Ins，怎么使用工具浏览和分析你的源码，更换编辑器等等。

在第九章《Logging Application Activities(记录程序行为)》里，他从.Net里现有的类(System.Diagnostics.Debug 和Trace)出发，谈到微软的Enterprise Instrumentation Framework以及The Logging Application Block，最后论及开放源代码的log4net。

在第十三章《Mastering the Build Process(精通Build过程)》里，他谈及自动Build 过程，以及该过程的简洁性和可靠性，分析比较了当前市面上高低档Build 工具，如何使用开发源代码的NAnt等等。

虽说自己开发软件也有不少年了，但惭愧的是，涉及的方面很有限。通过阅读这本书，了解到了自己与一个全面的软件开发人员间的距离，认识到在哪些方面还有待进一步提高。

比较欣赏书尾的几句话：

If there's one thing that distinguishes good developers from the rest of the pack, it's an attitude toward learning. Good developers just don't stop learning. There's always some new part of the software universe to explore, some new languages to learn, or some new tool to test-drive. As you hone your own developing skills, I urge you to make use of the resources of the Internet to continue learning and exploring.

[Collection]Charles Petzold给撰书人的建议

Charles Petzold给撰书人的建议
Charles Petzold 的千页著作《Applications = Code + Markup -- A Guide to the Microsoft Windows Presentation Foundation》已经交付印刷了，不久就会出版。

在他的博客里，他给想写书的人以下建议(粗浅翻译)：

Book-Writing Advice
http://www.charlespetzold.com/blog/2006/07/240338.html

1。保持一个平稳的时间表。每星期5-6天，每天大概6个小时，这样的安排，每个月足以写出100页来。
2。别无谓耽搁，别指望在最后几个星期内写完一本书，除非你是那位快笔作家西默农。
3。买个舒服的显示器，舒服的键盘，舒服的坐椅。这些是写书的最重要的计算机部件，处理器，内存，和储存都是次要的。
4。吃好，睡足。
5。千万别在写作当天把东西写尽，留点余味，下次再写时好上手(这是我从海明威那里学来的好建议)。如果写作当天结束时留下问题的话，空闲时你就会琢磨，也许等你下次坐到桌子前时，你已经在你的脑海里把问题解决了也没准。
6。试着保持一个平衡的生活。如果你一天内用功写书了，那么你做其他跟写书无关的事情时也不会有负罪感。
7。尽量避免大的分心，譬如新的电子玩具，一个新的关系，或者动手术。
8。也尽量避免小的分心。有些工作是可以在听电话和写电邮时同时进行的，但写书不属于这类工作
9。先写编码，然后写相关文字。
10。别怕跳跃。除非你知道以后章节都包含些什么内容，你是不知道前面章节应该写些什么的。
11。只求有进展，不求完美。
12。书写完后，给自己送个礼物，譬如一个新电子玩具，开始一个新的关系，甚至做个手术什么的。
13。书写完之前别理发。

-----上述经验对于个人完成一个大的编码项目或者撰写论文，我认为同样有效的。

LTP: socket模式 八十一难

唐僧西天取经经历了八十一难才取回真经。到目前为止，我所负责的LTP估计也快要经历八十一难的，但是还没有能完全达到理想的状况。为了解决旧版中资源重复加载而使得每次处理时间都比较长的问题，我们采用了资源常驻内存的Socket访问方式。原本在实现第一种访问模式的时候我已经经历了很多的困难。但是现在摆在面前的困难依旧有很多的。


此刻，我的头又一次出现了4月末开发LTP第一版的时候的那种情况，感觉有点电发疼。这种情况的原因不是因为呆在实验室编写程序的时间过长，因为我最近锻炼身体很到位的；而是因为面对的问题总是不能解决，在经历了好多种可能的解决方案后还是存在这样的问题。今天的问题有两个：socket通信的长字符串传输串位，以及TinyXML DOM的文本格式不能存放到char*中。到刚才截止，第二个问题找到了最终的解决方案，但是第一个问题还是不能找到原因。

没有办法，还得继续做呀，争取早日做完，早日解放呀！神啊，粗糙集概况和Name Disambiguation还在等待着我呢，我又一次陷入了项目的漩涡。现在的办法是把项目的需求明确到100％，当成是明确的编程人任务，而不是永无止境的研究。

在这里也要感谢我的偶像陈儒大虾和我的师弟刘龙，他们给了我编程方面很大的帮助并且提供了耐心的讨论。呵呵，八十一难就快满了，继续努力的啦！