3 ms·

Using symbolic math requires an amount of CPU/memory which is exponential in the number of operations applied, so is often (usually) not a practical or even pos

Using symbolic math requires an amount of CPU/memory which is exponential in the number of operations applied, so is often (usually) not a practical or even possible choice. You may think signed zero is a "fundamentally dumb idea" but it has helped a lot of people to accomplish their work, so... shrug. The basic issue is that numerical analysis is hard, and implementing numerical algorithms involves plenty of edge cases, so whoever is writing that code need to have a pretty good understanding of the problem and the tools and be willing to spend time on careful reasoning. Picking a slightly (or very) different number representation with different trade-offs doesn't really make it easier. Even if you (somehow) had a perfect number representation with infinite resolution and nearly free operations, you'd have to be careful when implementing numerical algorithms and would have to understand how to do error analysis and have an understanding of numerical stability etc. to design new ones.

adgjlsfhk1 2y ago
There's also Arb if you need guaranteed intervals to make sure you are on the right side of the branch cut. I completely agree that care and numerical analysis is necessary. My point is that once you've done the analysis, your actual answers aren't infinite (hopefully), and if your calculation returns Inf, it means that your program is wrong. Given that, you might as well just make the value of your function exactly on the branch cut NaN and be done with it.
- jacobolus 2y ago
  > if your calculation returns Inf, it means that your program is wrong In my own programs, e.g. working with rational approximations or more general functions which are meromorphic in big parts of their domain possibly with branch cuts, or representing the sphere using the stereographic projection, Inf is a commonly expected and entirely correct result, either of intermediate calculations or of final results, and is also a commonly expected program input. In my experience looking at other people's code it is relatively common for Inf to be a perfectly reasonable result of numerical calculations. In some contexts, underflow resulting in 0 or overflow resulting in Inf is a more precise result than 1.000000000000000. It all depends what your numbers represent and what you are trying to compute. (In some programs, it is even fine and ordinary to expect 0/0 or Inf/Inf resulting in NaN in intermediate computations, though these typically need to be checked for and special-cased so they can be recomputed to get the correct non-NaN but possibly Inf result.)

adgjlsfhk1 2y ago

There's also Arb if you need guaranteed intervals to make sure you are on the right side of the branch cut. I completely agree that care and numerical analysis is necessary. My point is that once you've done the analysis, your actual answers aren't infinite (hopefully), and if your calculation returns Inf, it means that your program is wrong. Given that, you might as well just make the value of your function exactly on the branch cut NaN and be done with it.

jacobolus 2y ago
> if your calculation returns Inf, it means that your program is wrong In my own programs, e.g. working with rational approximations or more general functions which are meromorphic in big parts of their domain possibly with branch cuts, or representing the sphere using the stereographic projection, Inf is a commonly expected and entirely correct result, either of intermediate calculations or of final results, and is also a commonly expected program input. In my experience looking at other people's code it is relatively common for Inf to be a perfectly reasonable result of numerical calculations. In some contexts, underflow resulting in 0 or overflow resulting in Inf is a more precise result than 1.000000000000000. It all depends what your numbers represent and what you are trying to compute. (In some programs, it is even fine and ordinary to expect 0/0 or Inf/Inf resulting in NaN in intermediate computations, though these typically need to be checked for and special-cased so they can be recomputed to get the correct non-NaN but possibly Inf result.)