UnitOneSummary

目录

• 一、程序结构分析
  • 第一次作业
  • 第二次作业
  • 第三次作业
• 二、Test & Bugs
• 三、设计模式
• 四、总结与反思

一、程序结构分析

第一次作业

思路：

1.输入预处理：

• 去除空格和\t
• 替换++、--、+-、-+
• 将+x，-x，x+，x-替换成+1*x，-1*x，x**1+，x**1-。至此已将输入中的每一项全部替换成[+-]\d+*x**[+-]?\d+
• 最后用正则提取每一项

2.合并化简求导

  HashMap<BigInteger, BigInteger>存储用正则提取的项的系数，指数，边提取，边比较，边化简

3.关于格式化输出

  因为系数和指数都是整数，所以求导之后只有指数是-2的项需要考虑系数是否为1或-1

  求导之后指数是0，直接输出系数；指数是1，如果系数还是1或-1，那么求导之前项的系数只能是分数，如果只按指数讨论，笔者的格式化输出逻辑减少5-6行，当然你也可以像第一次实验的输出要求一样讨论

UML:

LinesCounter:第一次代码总行数128

Metrics:第一次作业尚未飘红

第二次作业

思路：

1.判断表达式合法

• 去除空格和\t
• 判断是否为空串
• 以项为单位构造正则，逐项匹配

2.合并因子并求导：

​  构建求导的抽象类，每种函数继承抽象类，方便合并因子及求导

3.化简：

  合并同类项：

​    对于x，sin，cos的指数相同的两项，合并系数：重写了hashcode和equal方法，把x,sin,cos的指数当成三元组，把三元组当成Hashmap的key，系数当成Hashmap的value，通过判断是否containkey，进行同类项的合并

  分类：

​    按照x的指数分类，将系数，sin的指数，cos的指数当成三元组

​    对于指数不同的项无需考虑三角函数的化简

  对于每个x的指数对应的若干三元组深搜剪枝化简：

    设sin指数为m，cos指数为n，则对于①(m,n) ②(m,n+2) ③(m+2,n)

    ①②③任选两者的组合都可以转换成另选两组的组合。为方便讨论，设两项的公共部分为F，详细讨论如下：

​      ①+② <--> ①+③：a*F+b*F*cos(x)**2 <--> (a+b)*F-b*F*sin(x)**2

​      ②+③ <--> ①+②：a*F*sin(x)**2+b*F*cos(x)**2 <--> a*F+(b-a)*F*cos(x)**2

​      ①+③ <--> ②+③：a*F*sin(x)**2+b*F <--> (a+b)*F*sin(x)**2+b*F*cos(x)**2

​      类似转换方式还有：

​      a*F*cos(x)**2+b*F <--> -a*F*sin(x)**2+(a+b)*F

      a*F*cos(x)**2+b*F*sin(x)**2 <--> a*F+(b-a)*F*sin(x)**2

      a*F+b*F*sin(x)**2 <--> a*F*cos(x)**2+(a+b)*F*sin(x)**2

    利用可能使结果长度缩短的以上转换，进行深搜剪枝化简

  深搜：

    标记+回溯，对于每个没有被访问的三元组，尝试按照6种转化形式变换，递归到底之后判断总长度是否减小

  剪枝：

    采用贪心的思想，每次转换同时将转换之前的项设置成对照，如果未能使长度减小，直接return

  熔断：

​    根据第二次评测机2s限定的CPU时间，设定深搜部分的时间阈值1000ms，即超过1000ms之后直接throw exception

4.格式化输出：

​  重写toString

类之间的逻辑和调用关系：

LinesCounter:第二次代码总行数733

Metrics：化简部分的复杂度较高

第三次作业

思路：

1.判断表达式合法：

• 排除空串(只有空格和\t的也算作空串)
• 排除非法字符
• 排除空格引发WF的情况
  • 排除非法阶乘
  • 排除非法三角函数
  • 排除非法数字
  • 去掉空格和制表符
• 排除非法加法减法符号
• 排除非法指数和底数
• 排除不匹配的括号

2.求导：

​  只对表达式因子和嵌套类的三角函数建树处理，其余正常处理。建树时按照优先级嵌套>乘法>加法=减法，设置权重，方便建树

3.化简：

​  求导结果只有*,+,-，所以递归化简，去除多余的0，1，括号

4.格式化输出：

​  重写toString

类之间的逻辑和调用关系：

LinesCounter:第三次作业总行数1508

Metrics：由于循环和判断逻辑较多，所以大面积飘红

二、Test & Bugs

Test:

​  在第一次作业强测之前已搭建好评测机，三次作业使用只需改变生成数据的正则

思路：

• 1.用xeger根据自己设计的正则表达式批量生成测试数据的文件input.txt
• 2.然后将input.txt逐行作为输入 ,运行.class 获得输出文件tmpOutput.txt
• 3.然后对tmpOutput.txt的内容采用sympy进行表达式求值(比如代入x=2),获得输出文件myOutput.txt
• 4.用sympy包对input.txt的内容逐行求导并进行表达式求值,令x=2,获得输出文件correctOutput.txt
• 5.比较myOutput.txt和correctOutput.txt,如果存在不同,根据行数查找input.txt的测试数据

按照1-5的逻辑编写.sh ，bash运行完成黑盒测试

具体细节处理：

1.1去除生成数据的前导0

#去除前导0
str = re.sub(r'(?<!\d)0+(?=\d)', "", str)

1.2 代入2计算

result = int(expr.evalf(subs={x: 2}))

1.3 使用管道，简化sh编写

cat $InputFileName | while read line
do
	...
	correctOutput=$(echo "$line" | python diff.py)
	result=$(echo "$myOutPut$space$correctOutput" | python compare.py)
	...
done

另一种测试方法：Junit

//本次主要使用sh
import org.junit.Test;
import JUnitTestTools.EnhancedUserTestTools;
import java.io.File;

public class PolyTest {

    @Test
    public void main() throws Exception {
        new EnhancedUserTestTools(Poly.class, 2000).testAll(new File("./test/poly/test1.txt"));
    }
}

Bugs

强测：

​  三次强测均未测出bug

hacked:

​  三次互测均未被hack

hack:

​  三次互测平均每次hack非同质bug2个，其中主要是输出时toString的逻辑和细节处理，以及第三次作业存在的优化过度的问题。

三、设计模式

​  主要采用工厂模式。

​  第一次作业由于仅用128行实现，没有考虑向后兼容性，所以没有设计工厂（之后单元应该着重注意代码向后兼容的能力）

​  第二次作业考虑了向后兼容性，设计了抽象类，sin,cos,pow,const均继承抽象类，搭建工厂

​  第三次作业在第二次作业的基础上，实现递归逻辑。配合树结构的使用，保证了正确性

四、总结与反思

​​  三次作业主要锻炼了各个容器的使用，工厂模式的应用，优化方式的探索。虽然三次作业的完成都保证了正确性，但尚有很多不足。比如第三次作业中采用二叉树的结构，①是给后续的化简带来极大的困难，②是树结构与业务逻辑紧密绑定，可能无法满足后续的扩展要求。但是如果设计一个统一的item接口，然后不仅让sin,cos,pow,const实现这个接口，而且让各个组合项+,-,*,嵌套也实现这个接口，只需要组合项是内置两个item一个operator，不仅方便化简，而且无需采用树结构，简化代码逻辑，同时能保证向后兼容性，无论之后出现新的因子，还是新的组合模式，只要实例接口即可。

​​  相比于正确实现功能，个人认为优化部分更具有挑战性，尤其是在优化的同时，保证正确性，而不是因为20分失去应得的80分。比如在第二次作业中，采用了dfs深搜的优化方式，但可能会出现TLE的问题，所以要设置熔断。在第三次作业中，如果采用二叉树，可能面临无从化简的处境。