Spotted by Claude, reproducer by me:
(%i1) assume(notequal(x, 0))$
(%i2) facts();
(%o2) [notequal(x, 0)]
(%i3) limit(sqrt(x^2+a), a, 0);
Is x positive or negative?
pos;
(%o3) x;
(%i4) facts();
(%o4) []
The fact notequal(x, 0) has disappeared!
Fix coming.
The limit code is barely documented, it uses constructs that aren't easily understood, it is intertwined with many things, it has many bugs and it isn't too fast => would that be the right moment to give claude access to the project directory and ask it for a stability review, a correctness review and an architecture review of that functionality with the goal of having a test for every single fringe case in that functionality? Normally in such cases it comes with a plan on how to do such things in lots of cautious steps for which normally there is a way to proof the correctness for most parts and a warning and a question if one wants to go that risk if that isn't the case.
That's more or less what I'm doing. All these bugs that I reported/fixed over the last days/weeks/months were detected by Claude or Gemini. I don't dare to ask it for a complete rewrite, though.
Exactly. Fixing individual bugs is extremely valuable and tends to improve the overall quality of code. But if there are many that normally is a symptom of a architectural/structural problem and it always is more efficient to catch bugs by the root. Often on the architecture level it is possible to prevent whole classes of bugs from forming, in the 1st place. I would advise you to try it once in a private branch. Normally claude widely surpasses expectations in those settings, expecially claude 5.0.
I meant opus 5.0
Oh, and in defense of limit: This bug was actually not caused by limit, but by
asksign-p-or-n.And you are doing extremely good work => My advice is only meant as a advice to try it once because with wxMaxima that approach ended with a vastly improved speed, stability, maintainability, whole classes of bugs being made impossible. Then claude scanned the bug reports from the last years and the git commits for recurring bugs and added regression tests without me even asking for that (but it had enough proof that I like tests). And to read what it writes about its work: It rarely gets things wrong but if it does it tends to actually learn by analyzing why it did to so and saving the analysis results to memory.
That might be another hint on man things being intertwined and an architecture review might make things way easier including: With a bit of luck it splits the system into small programs that allow to write short test programs that make it way easier to verify assumptions about things like the assumptions database instead of hoping to have understood the code right.
In my experience an architecture review with the goal of testability and robustness finds and resoles many bugs. Also you can tell opus to document non-self-explaining code, but to do so only if it is really sure it has understand the code and won't tell anything misleading. Normally that works and if it doesn't and you tell it that normally that will result in opus correcting the bug that lead it to the wrong belief.
Fixed by commit [ef7ada].
Regarding AI-based architectural fixes: I can imagine how this can work nicely for a program like wxMaxima, which is relatively new and self-contained. But Maxima has grown for 50 years or so and is deeply entangled with decades-old Lisp paradigms, global state mutations, and dynamic scoping. Any fundamental architectural change risks breaking backwards compatibility for countless user scripts that unknowingly rely on its historical quirks. For now, I will keep using AI as a surgical tool for hunting localized bugs, mapping side effects etc.
Related
Commit: [ef7ada]