Floating point arithmetic in computers is usually not precise, and has many failure modes that are hard to understand even for experts.
Floating point arithmetic might not be precise, but it’s in-precise in KNOWN ways.
As in, for a given operation done given a certain set of instruction you can know that cases X/Y/Z have undefined behavior. (e.g. using instruction A to multiply c and d will only give a precise result up to the nth decimal place)
By your same definition basically every single popular programming language is not precise since they can manifest UB, but that doesn’t stop your kernel from working since it’s written in such a way to (mainly) avoid any sort of UB.
Pragmatically speaking, I can take any FP computation library and get deterministic results even if I run a program millions of times on different machines.
Heck, even with something like machine learning where your two main tools are fp operations and randomness you can do something like (example for torch):
and you will get the same results by running the same code millions and millions of time over on many different machine.
Even if the library gets itself in an UB situation (e.g. number get too large and go to nan) , it will be precisely reach that UB at the exact same point each time.
So I think the better way to think of FPA is “defined only in a bounded domain”, but the implementations don’t bother to enforce those definitions programatically, since that would take too long. Saying nan is cheaper than checking if a number is nan each time kinda thing.
Floating point arithmetic might not be precise, but it’s in-precise in KNOWN ways.
As in, for a given operation done given a certain set of instruction you can know that cases X/Y/Z have undefined behavior. (e.g. using instruction A to multiply c and d will only give a precise result up to the nth decimal place)
By your same definition basically every single popular programming language is not precise since they can manifest UB, but that doesn’t stop your kernel from working since it’s written in such a way to (mainly) avoid any sort of UB.
Pragmatically speaking, I can take any FP computation library and get deterministic results even if I run a program millions of times on different machines.
Heck, even with something like machine learning where your two main tools are fp operations and randomness you can do something like (example for torch):
and you will get the same results by running the same code millions and millions of time over on many different machine.
Even if the library gets itself in an UB situation (e.g. number get too large and go to
nan) , it will be precisely reach that UB at the exact same point each time.So I think the better way to think of FPA is “defined only in a bounded domain”, but the implementations don’t bother to enforce those definitions programatically, since that would take too long. Saying
nanis cheaper than checking if a number isnaneach time kinda thing.