个人作业:词频统计
个人作业:词频统计
Github项目地址:https://github.com/USTChuomiao/homework1/blob/master/PB15061351/hw1.cpp
PSP
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 5 | 3 |
· Estimate | · 估计这个任务需要多少时间 | 5 | 3 |
Development | 开发 | 1125 | 1235 |
· Analysis | · 需求分析 (包括学习新技术) | 3 * 60 | 4* 60 |
· Design Spec | · 生成设计文档 | 30 | 40 |
· Design Review | · 设计复审 (和同事审核设计文档) | 5 | 5 |
· Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
· Design | · 具体设计 | 30 | 30 |
· Coding | · 具体编码 | 8 * 60 | 9 * 60 |
· Code Review | · 代码复审 | 30 | 40 |
· Test | · 测试(自我测试,修改代码,提交修改) | 6* 60 | 5.5 * 60 |
Reporting | 报告 | 60 | 60 |
· Test Report | · 测试报告 | 20 | 30 |
· Size Measurement | · 计算工作量 | 10 | 10 |
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 20 |
合计 | 1190 | 1298 |
项目要求:
1、目标:对源文件(*.txt,*.cpp,*.h,*.cs,*.html,*.js,*.java,*.py,*.php 等,文件夹内的 所有文件)统计字符数、单词数、行数、词频,统计结果以指定格式输出到默认文件中,以及其他扩展功能,并能够快速地处理多个文件。
2、要求:设计 10 个测试样例用于测试,确保程序正常运行(例如:空文件,只包含一 个词的文件,只有一行的文件,典型文件等等)。
解决思路:
1、首先做了一个初步的规划: (1)文件夹的遍历;
(2)统计单个文件中的字符数、行数、单词数;
(3)对每个单词以及出现次数进行存储;
(4)对每个词组以及出现次数进行存储;
(5)找出词频前十的单词和词组并输出。
2、完成对一个路径内所有文件的遍历。起初在windows环境开发,学习了网上的一些操作之后,结合自己的想法,决定用栈来辅助所有文件的遍历。先打开一个文件夹,如果是文件夹将其路径存入栈中,如果是文件继续遍历,完成当前文件夹遍历之后,从栈中弹出一个路径继续重复上述操作,直到栈空即所有文件都被遍历了。后期将代码移植到 linux 环境下,采用递归的方法遍历所有文件。
3、统计一个文件中字符数、行数、单词数,字符数和行数没什么好说的,主要是单词的提取。根据给出的单词的定义,设计了一个提取单词的算法:把当前字符用ch来存储,它的前一个字符用chr来存储,首先若满足word[0]为空、chr为非数字和字母的分隔符、ch为字母这三个条件,则将ch存入word[0];继续读取字符,若word不为空且ch为字母,则存入word,若word长度大于4,ch为数字亦存入word;当ch读到一个分隔符时,即不满足上述条件时,检测当前word长度是否大于4,若大于则成功提取一个单词,反之清空word;重复上述操作即可将文件中单词提取出来。
4、存储并统计单词出现次数,起初考虑了用结构体数组、文件、树来存储,但是想了想感觉存储空间或者运行速度上会受到限制,最后采用Hash Table通过动态链表的形式存储单词及其出现次数。这个Hash Table最初想到以26个字母对应26个头指针的形式,后来升级到26*26*26*26个头指针,即依据单词的前四个字母进行检索。从刚刚成功提取单词那里调用一个对单词进行处理的函数,这个函数大概算法是这样的:首先找到这个单词对应的头指针,然后顺着头指针的链表依次对比两个单词的大小(通过ASCII码),直到找到一个相同单词的位置,就把他的词频数+1,或者找到介于两单词之间,就创建节点插入链表(这个过程中相同有是否替换单词形式的判断过程)。直到把所有单词都存入Hash Table即完成任务。(这样存储进去的单词若从Hash Table头开始遍历即是词典顺序)
5、词组的统计和单词类似,只需对提取单词的操作稍加改动,即可完成词组的提取。同样词组存入词组的Hash Table的操作也同单词类似。
6、输出词频前十的单词和词组,首先提取所有词频存入数组(单词和词组分开操作,并过滤掉相同词频数),找出词频数最大的十个,然后由刚找到的前十词频去遍历Hash Table输出十个单词或词组就停止。(注意:十个词频数不一定全用到,可能有两个或多个单词或词组词频数相同)
Linux下对代码质量进行分析:
gprof是gcc/g++编译器支持的一种性能诊断工具。只要在编译时加上-pg选项,编译器就会在编译程序时在每个函数的开头加一个mcount函数调用,在每一个函数调用之前都会先调用这个mcount函数,在mcount中会保存函数的调用关系图和函数的调用时间和被调次数等信息。最终在程序退出时保存在gmon.out文件中。
这次代码做的主要优化是Hash Table的长度改变,从 26 变成 26*26 到最终的 26*26*26*26 可以明显的感觉到速度的提升。
还有一些小的优化就是词组提取过程中要访问单词的哈希表,起初采用了整个哈希表遍历的方式,后来发现只需要遍历对应行的单链表即可,也节省了不少时间。
下边这些数据是优化后的代码数据。
1、> g++ -pg -g -o h hw1.cpp
> ./h code/test6
运行完之后生成了 gmon.out 文件。
2、> gprof h gmon.out -p
得到了每个函数的性能参数,时间占比什么的。。。
3、> gprof h gmon.out -q
得到了函数之间的调用关系。。。
4、> gprof h gmon.out -A
测试用例及分析过程:
根据作业的要求,设计了十个测试集,完成并验证了符合作业要求。(这里只列出六个做以说明。)
test1:多层多个不含任何文件的空文件夹集。
测试结果:所有结果都是0,测试正常,结果正确。
test2:文件夹中仅包含三个空文件。
测试结果:字符数、行数、单词数都是0,文件数:3,测试正常,结果正确。
test3:test3.txt文件内容:file123 123file File///FILE; (同时也算测试了路径为单个文件程序也能照常运行)
测试结果:123file没有被算作单词,file123、FILE、File是同一个单词FILE,测试正常,结果正确。
test4:包含windows95、windows7、windows、windows32a、iPhone4、IPhone5的测试集。
测试结果:windows95、windows7都看作是和windows是同一单词,但和windoes32a不是同一单词;
iPhone4和IPhone5被认为是IPone5,测试正常,结果正确。
test5:文件夹中仅包含4个.txt大文件。
测试结果:和某同学对相同文件夹测试得到结果基本相同。测试正常,结果正确。
test6:文件夹中包含各种类型的文件。
测试结果:和某同学对相同文件夹测试得到结果基本相同。测试正常,结果正确。
此次项目获得的经验:
在此次项目的开发测试过程中,首先对问题的分析和解决方案的选取很重要,要把解决策略步骤化,代码模块化,并作模块化调试之后再联合调试。其次在写程序的时候要不断学习吸收新的知识,另外在debug的时候最好有个伙伴在旁边,这样能帮助你很快的解决一些小问题,节省很多时间。最后在完成初步调试通过后,要进行多方面多层次的大量测试,从中发现问题并改进,以确保代码的稳定性和正确性。