Searching for fast complex numbers in C99 and C++

So, if you read the article you will learn the float handling is done in software.

I find this harkens well to a lot of heavily modeled frameworks. How many people truly need everything you get with the latest React/etc?

I realize these aren't directly comparable. However, it is hilariously depressing how many "dynamic" sites would be better served by a simple static html file.

Rounding behavior is important for more than medical imaging and physics simulations. Many embedded systems controlling or sensing something in the real world care about it. Not just things like cars and planes, but imagine control loops designed for up-times of years that suddenly serious numerical stability issues because part of the IEEE standard got thrown out.

I do physics simulations and I generally use -ffast-math. For most simulation types, proper algorithms are stable with respect to small floating-point errors (this has been a subject of research for decades).

The extra speed provided by imprecise math allows for bigger, longer simulations, which ultimately means more accuracy than what is lost in the floating-point operations.

Wasted? Well, if you don't care for video editing, image processing, 3D modeling...

A well defined floating point implementation is everyones benefit.

I don't have an idea of how much it matters for which percentage of programs, but here are some anecdotes of what can happen when not caring about NaN and rounding.

We had a bug once which was really hard to track down. Turned out a simple lack of initialization of a variable in a simple piece of code for a running average: the programmer reasoned in the first iteration this number is going to be multiplied with 0.0 anyway, so no need to initialize it. However because there are many NaN representations, once in a while the uninitialized memory of the variable happened to represent NaN, and NaN * 0.0 is still NaN, and that would keep on propagating, oops.

Likewise for rounding: we had some code calculating pixel positions and sometimes stuff was one pixel off resulting in weird visual artefacts. Turns out that when feeding the (faulty) rounding algorithm with results of some floating point calculations wouldn't do the expected thing but round down instead of up or so. Oops.

Consistent rounding behavior matters when you need reproducibility. For example, videogames often reproduce computations as part of their networking systems, and if different users have different rounding behavior, it'll break.

I was running MCMC for a while just in probability space. That didn't last long! It's tremendously useful to work in log probability space. It adds tremendous expressivity close to zero plus makes most multiplications sums. I think similar methods are probably used in other sectors.

What I found remarkable though was the big difference I saw in old versus new compilers with respect to the diversity of random numbers generated. I first thought that it was the entropy available on my system but that didn't turn out to be the key factor. So watch out for old compilers!

The bummer about this to me is that the c99 guys took it upon themselves to extend IEEE semantics to complex numbers. To do that, you have to decide on a representation for infinity in complex numbers (there's really only one mathematically). They choose isinf(re(x)) || isinf(im(x)), so among other things, Inf + Nan*i is considered infinite...ok. And then they tried to make things consistent between real and complex numbers with this (made up) notion of complex infinity.

The result being that there's edge cases they have to back up and 'fix' to be consistent. However, they could have just decided that complex arithmetic semantics follow naturally from floating point and whatever results ensue. So in the end this was all self-inflicted.