3 ms·

The "rewrite engine" ambitions for Fungrim seem potentially misplaced. It would probably be better to contribute to an existing open source state-of-the-art CAS

by nsajko 7y ago

The "rewrite engine" ambitions for Fungrim seem potentially misplaced. It would probably be better to contribute to an existing open source state-of-the-art CAS like Fricas, than to make another one. The article tries to justify this in a weird way: > Computer algebra systems can be viewed as having three components: a way to represent mathematical objects, algorithms for manipulating such objects, and user interfaces around this. The various components are usually entangled with each other without cleanly separating different levels of abstraction, so there is a lot of incidental complexity. So? That is no reason to make another CAS, as opposed to helping refactor Fricas. > The algorithms are incorrect by design, typically for efficiency reasons. A good example is ignoring special cases and assumptions on the variables when simplifying symbolic formulas (some examples given above). Another example is pretending that floating-point numbers are the same thing as real numbers. Calculating nonrigorously is not necessarily the wrong approach; it all depends on the application. It's sometimes better to do something fast and simple (but possibly incorrect), especially if the result can be checked afterwards. Sometimes you really want every step to be correct, even if it takes longer time and requires more complicated user input. For better or worse, current computer algebra systems are largely designed around the "fast and simple" principle, with optional correctness added more as an afterthought (and often not fully supported). WTF! Only if one uses Wolfram Alpha exclusively! Another comment [0] by fdej (the author) I just found by accident has some related misconceptions: > However, nothing open source currently comes close to Mathematica for symbolic and symbolic-numerical calculus (expression simplification, symbolic integration, solving PDEs, etc.). Try Fricas. > Also, one of Mathematica's main strengths is providing a lot of functionality in a neat package where diverse components are very easy for the user to glue together, with automagical interfaces where the user doesn't need to know what happens behind the scenes "Automagical" interfaces suck, they will inevitably break when you stray just a bit from the intended path. It is better to have a typed language like Fricas has. [0] https://news.ycombinator.com/item?id=17694483 https://news.ycombinator.com/item?id=17694483

fdej 7y ago
All good remarks. > The "rewrite engine" ambitions for Fungrim seem potentially misplaced. It would probably be better to contribute to an existing open source state-of-the-art CAS like Fricas For the record, I have contributed to several existing open source computer algebra systems (not Fricas though). I honestly don't think anyone has found the right foundations for computer algebra systems yet. Nor do I even think that there can necessarily be a "one size fits all solution" that works better than a multitude of specialized systems for different tasks. Fricas gets some things right where others don't, but it has its own weaknesses. I think it's valuable to explore different approaches. This possible future direction for Fungrim is more of a research project, and in any case, I think it's complementary to much of the work that is already being done on other open source computer algebra systems. Sorry that this is still a bit vague. I have more specific issues in mind, but I don't have time to elaborate in this HN comment. I hope to do a better writeup in the future! > WTF! Only if one uses Wolfram Alpha exclusively! Or Maple, or Maxima, or SymPy, or Sage, or... even Fricas. Despite its type system, Fricas has the same problem as the rest with overzealous simplification. One of the very first examples in the Fricas book, "integrate (1/(x^2 + a),x)" gives a result that isn't valid when a = 0... And that's without even digging to look for something more subtle that will be more likely to catch the user off guard. > Try Fricas. I admit that I haven't tried Fricas in a long time, but I'm also confident that I wouldn't need to look hard to find examples. Here is just one quote from the Fricas book: "FriCAS can compute some forward Laplace transforms, mostly of elementary functions not involving logarithms, although some cases of special functions are handled." Mathematica, on the other hand, handles a huge number of Laplace transforms involving logarithms and special functions (largely using Meijer G-function methods in combination with internal lookup tables and many different heuristics). How well does Fricas support definite integration with piecewise functions or functions involving branch cuts? Mathematica has improved a lot in this area in the last few years (even if it isn't perfect). Of course, I'm sure Fricas has its strong areas too, and Mathematica is terrible in some areas. > "Automagical" interfaces suck, they will inevitably break when you stray just a bit from the intended path. It is better to have a typed language like Fricas has. Oh, I do agree completely about the problem with automagical interfaces that work until they don't :) Nevertheless, even "automagic" that breaks down at some point is great for discovery and prototyping. I think in many cases, we can do a better job providing interfaces that scale smoothly between automatic and user-controlled.

by nsajko 7y ago

fdej 7y ago

All good remarks. > The "rewrite engine" ambitions for Fungrim seem potentially misplaced. It would probably be better to contribute to an existing open source state-of-the-art CAS like Fricas For the record, I have contributed to several existing open source computer algebra systems (not Fricas though). I honestly don't think anyone has found the right foundations for computer algebra systems yet. Nor do I even think that there can necessarily be a "one size fits all solution" that works better than a multitude of specialized systems for different tasks. Fricas gets some things right where others don't, but it has its own weaknesses. I think it's valuable to explore different approaches. This possible future direction for Fungrim is more of a research project, and in any case, I think it's complementary to much of the work that is already being done on other open source computer algebra systems. Sorry that this is still a bit vague. I have more specific issues in mind, but I don't have time to elaborate in this HN comment. I hope to do a better writeup in the future! > WTF! Only if one uses Wolfram Alpha exclusively! Or Maple, or Maxima, or SymPy, or Sage, or... even Fricas. Despite its type system, Fricas has the same problem as the rest with overzealous simplification. One of the very first examples in the Fricas book, "integrate (1/(x^2 + a),x)" gives a result that isn't valid when a = 0... And that's without even digging to look for something more subtle that will be more likely to catch the user off guard. > Try Fricas. I admit that I haven't tried Fricas in a long time, but I'm also confident that I wouldn't need to look hard to find examples. Here is just one quote from the Fricas book: "FriCAS can compute some forward Laplace transforms, mostly of elementary functions not involving logarithms, although some cases of special functions are handled." Mathematica, on the other hand, handles a huge number of Laplace transforms involving logarithms and special functions (largely using Meijer G-function methods in combination with internal lookup tables and many different heuristics). How well does Fricas support definite integration with piecewise functions or functions involving branch cuts? Mathematica has improved a lot in this area in the last few years (even if it isn't perfect). Of course, I'm sure Fricas has its strong areas too, and Mathematica is terrible in some areas. > "Automagical" interfaces suck, they will inevitably break when you stray just a bit from the intended path. It is better to have a typed language like Fricas has. Oh, I do agree completely about the problem with automagical interfaces that work until they don't :) Nevertheless, even "automagic" that breaks down at some point is great for discovery and prototyping. I think in many cases, we can do a better job providing interfaces that scale smoothly between automatic and user-controlled.