OO第一单元作业总结

[康建平-ZC061006]

一、架构设计

1.最终架构

最终架构如下

 

2.第一次迭代

 第一次迭代总体没什么问题，但是toString方法只能按照指数排序输出，没有做把正系数项提到第一位的长度优化。

3.第二次迭代

架构变化

	HW1	HW2
核心类	Polynomial	Expr(在polynomial基础上增加支持exp的广义表达式）
项结构	coeff*x^exp	coeff*x^exp*exp(inner)
函数	无	新增Function类用来管理f(x)部分
选择算子	无	[(A==B)?C:D]

新增方法

• Lexer新增token
• Lexer新增解析方法-解析exp(  f(  ==
• Parser返回类型改为Expr。新增分支exp(factor),f(factor),[(A==B) ?C:D]
• 新建Expr类，在polynomial基础上能实现函数展开，exp处理，和exp内部公因数提取等功能

bug与缺点

第二次迭代主要错在处理三目表达式时没有惰性求值，所以经常超时。于是bug修复阶段增加了skipfactor等方法辅助。

还有就是exp指数处理时没有进行公因数提取，导致输出过长，性能较差。

4.第三次迭代

架构变化

	HW2	HW3
变量	只有x	双变量x,y
项结构	coeff*x^a*exp(inner)	coeff*x^a*y^b*exp(inner)
求导	无	dx,dy,grad算子
函数类型	普通函数	普通+递归函数

新增的方法&改动

• ExpTerm新增y指数
• Expr改动：已有方法增加yExp参数，增加方法ofY创建y^b。
• Expr新增deriveX,deriveY求导方法
• Lexer新增解析y，dx,dy,grad,f{....方法
• 新增RecFunction用来管理f{n}(x)部分

bug与缺点

本次迭代完成基本功能后又“优化”了exp输出——提取exp内部表达式的公因数，然后与完全展开的表达式比较，输出最短的那个。虽然这个优化会保证输出变短，但是互测时经常被卡，处理exp(exp(exp(exp(exp(exp(x)^2)^2)^2)^2)^2)^2这种数据就会超时。

原因在于：

 addTerm 每次都要调用 expInner.toString()，而 toString() 会递归遍历整个嵌套 exp 结构。在 multiply/add/substitute
 时同一个 expInner 的 toString() 被重复调用，对于深度为 d 的嵌套，复杂度是 O(2^d)。

修复方法：
  1. 新增 cachedToString 字段缓存结果
  2. addTerm 修改 terms 时使缓存失效（cachedToString = null）
  3. toString() 优先返回缓存，否则计算后存入缓存

修改后复杂度降为O(d)

二、度量分析

1.类分析

 没有数据的那几个是没用但是还没删掉的文件

2.方法分析

 

 

 三、大模型使用

 不同于OOpre天天手搓代码，u1本人确实频繁使用大模型编程。三次作业AI使用率大概为60%。

1.架构提供方向：迭代时有时候感觉架构摸不着头脑，对于某些特定的问题不知从哪儿入手，这时候我就会询问大模型，让他给我一些方向，以完善我的架构。

2.辅助生成代码：比如对于Lexer类中nextToken()和getCurrent()等方法，逻辑简单但是十分冗长，这种我就会让大模型辅助生成。

3.debug：丢给AI代码和题目要求，让他找bug，确实能快速定位简单的bug。如果弱测没过，告诉他特定样例，也能有效定位bug。但是，大模型debug仅停留在题目层面，有些深层次的东西的东西他没法想到。比如我的三目表达式惰性求值和第三次作业的exp公因数提取优化，只有你自己指出这些问题，他才能给出解决方法。

4.互测使用大模型：本人互测两次b房，一次a房，曾尝试用大模型分析同组同学的代码，试图找到bug，但是从未成功过，就跟上面说的一样，AI比较善于查找输出错误的问题，但是对于性能优化，尤其是运行时间方面，他真的不怎么会，更不会出恶心的样例。

 

四、心得体会

本次U1作业让我重拾了上学期java的知识，也让我对递归下降这种方法有了深刻的认识。由于第一次作业上手毫无头绪，写的乱七八糟还得重头改，导致我的架构很乱，希望以后的作业能改进这一点，也争取以后写作业能减少对ai的依赖，坚持独立完成架构和新方法的创建。

五、未来方向

希望以后课程组可以在第一次作业时多提供一些架构方向，降低上手难度。