For a high-level API, shouldn't this be expressed with types such as a `Result<T,E>` at the library level?
edit: now that I think about it, that would require some really nice optional chaining syntax to be even slightly usable.
Oh now I'm curious if IEEE 754 NaN rules are isomorphic to a number optional type with monadic chaining syntax
Basically. And you can stick error codes in the value too, so you can know down the line what caused the NaN.
There are no NaN values in the real numbers.
You need some way to cope with operations that don’t have real results for some values, such as log and sqrt of negative numbers
you can just represent those as a pair of real numbers, one for the real part, and one for the imaginary part. As long as you only (recursively) apply exponential and trig functions on those numbers, I believe you'll stay within the realm of complex numbers.
0/0, tan(pi/2), log(0)
I was replying to the sqrt and log of negative numbers. For undefined functions, I'd throw an exception
True, but I thought this was about real arithmetic not complex arithmetic
The paper says the Java code throws exceptions in such cases.