
A Grimoire of Functions - akalin
http://fredrikj.net/blog/2019/05/a-grimoire-of-functions/
======
peter_d_sherman
Seconded! Fredrik is a hero.

Favorite line:

"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!"

Indeed! (And a mathematical IDENTITY... as are many others in this
"Grimoire"...)

Great work, Fredrik!

~~~
jacobolus
> _Discovered around 1740 by the Swiss Sorcerer Supreme_

And earlier published in 1714 by the Englishman Roger Cotes.

------
wbl
See also Abramowitz and Stegun, of which the latest edition is
[https://dlmf.nist.gov/](https://dlmf.nist.gov/)

~~~
tigerlily
They have a really nice changelog.

------
chewxy
This is a delightful read. It has the neuroticism of someone whom I admire
quite a lot and yet has the urge of curiosity. Thank you.

------
nsajko
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
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.

------
nixpulvis
This is awesome. I have just started
[https://nixpulvis.com/math/10-overview](https://nixpulvis.com/math/10-overview)
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.

------
drallison
Great idea. It might be more useful if it were compatible to and integrated
with jupyter notebooks which has become widely used. See
[https://www.jupyter.org](https://www.jupyter.org) for more information.

------
nsajko
> [Regarding CAS-es:] Another example is pretending that floating-point
> numbers are the same thing as real numbers.

What kind of lousy CAS does not support arbitrarily precise numbers? For
example Fricas/Axiom/Scratchpad gives arbitrarily precise results.

~~~
fdej
Arbitrarily precise is not the same as exact. There are many possible examples
to illustrate why this matters. Here's one: let's say that you compute
floor(f(x)) where f(x) falls right on an integer n. If you evaluate f(x) in
floating-point arithmetic, you probably get n +/\- epsilon and not n exactly
because of rounding errors. This makes the floor function go to either n or n
- 1, so you sometimes end up with an error of 1 no matter how precise the
floating-point numbers.

~~~
gweinberg
Right, and with a little extra effort, you can make an arbitrarily small error
in one of your terms give a result that can be anywhere from negative infinity
to positive infinity.

------
mruts
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?

~~~
HelloNurse
Lisp macros are meant to rewrite S-expressions that represent source code in
controlled, predictable and well-behaved ways, whereas S-expressions in
Fungrim represent data and they can be transformed in generic and aggressive
ways to deduce something useful.

Different purposes, with different needs and only a limited technology overlap
(the theory of how to maintain program correctness through transformation is
related to the theory of how to squash hidden assumptions and subtle type
mismatches in algebraic formulas).

~~~
mruts
I think you misunderstand the genericicity of macros in Lisp. Macros take one
or more S-exps and return and S-exp. nothing more, nothing less.

There’s no reason why macros need to generate valid code. Though in Lisp, it’s
pretty easy to make any code you want valid.

------
jrumbut
Not a bad TeX reference either, great stuff!

------
alpineidyll3
Awesome! This guy's a hero.

~~~
fdej
Cheers :)

------
meantheory
a grimoire never sounded so cool

