Seconded! Fredrik is a hero.<p>Favorite line:<p>"Euler's formula... Discovered around 1740 by the Swiss Sorcerer Supreme, Leonhard Euler, this formula can transmute exponentials into trigonometric functions and vice versa. A magic formula indeed!"<p>Indeed! (And a mathematical IDENTITY... as are many others in this "Grimoire"...)<p>Great work, Fredrik!
See also Abramowitz and Stegun, of which the latest edition is <a href="https://dlmf.nist.gov/" rel="nofollow">https://dlmf.nist.gov/</a>
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:<p>> 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.<p>So? That is no reason to make another CAS, as opposed to helping refactor Fricas.<p>> 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).<p>WTF! Only if one uses Wolfram Alpha exclusively!<p>Another comment [0] by fdej (the author) I just found by accident has some related misconceptions:<p>> However, nothing open source currently comes close to Mathematica for symbolic and symbolic-numerical calculus (expression simplification, symbolic integration, solving PDEs, etc.).<p>Try Fricas.<p>> 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<p>"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.<p>[0] <a href="https://news.ycombinator.com/item?id=17694483" rel="nofollow">https://news.ycombinator.com/item?id=17694483</a>
This is awesome. I have just started <a href="https://nixpulvis.com/math/10-overview" rel="nofollow">https://nixpulvis.com/math/10-overview</a> as a way to index notation and LaTeX syntax for myself. I'll be sure to read though this from time to time. I was going to start adding D3 and all that, but now I'm wondering if I can just incorporate this. I too am using MathJax.
Great idea. It might be more useful if it were compatible to and integrated with jupyter notebooks which has become widely used. See <a href="https://www.jupyter.org" rel="nofollow">https://www.jupyter.org</a> for more information.
> [Regarding CAS-es:] Another example is pretending that floating-point numbers are the same thing as real numbers.<p>What kind of lousy CAS does not support arbitrarily precise numbers? For example Fricas/Axiom/Scratchpad gives arbitrarily precise results.
Very nice! But is Python the right choice for this? It seems like the macro rewriting abilities of Lisp (especially Racket) would be a perfect fit for this project. And he's already using S-exps, so why reinvent the wheel?