3 ms·
> In "safe" languages we often talk about how you can't ignore errors in return values. It’s pretty important to define what you mean by “error”. We should not
by dahart 6y ago
> In "safe" languages we often talk about how you can't ignore errors in return values.
It’s pretty important to define what you mean by “error”. We should not conflate state or execution errors with approximation errors, they are very very different kinds of errors. It is quite often not an error condition to have an approximation, and so would not count as a “leak”.
> If it only takes 6k lines to provide an API for more precise real numbers, then almost every programming language should have it.
There are a lot of libraries in a lot of languages for supporting arbitrary precision, big numbers, and other various representations. I’d venture to say that almost every programming language does have it, if you count a third party or open source library as having it.
On the other hand, high precision reals is a performance drain of enormous magnitude if you don’t always need it. Do keep in mind that even with all their problems, 32 bit floats and 64 bit doubles are really fast compared to software number libraries, the IEEE formats have broad hardware support that doesn’t exist for high precision reals.
- ogogmad 6y ago> There are a lot of libraries in a lot of languages for supporting arbitrary precision, big numbers, and other various representations. I’d venture to say that almost every programming language does have it, if you count a third party or open source library as having it. Arbitrary precision is very different from exact real arithmetic.
- dahart 6y agoSure I agree completely and didn’t mean to suggest otherwise. Most languages have implementations of all the above - attempts at certain types of exact real, arbitrary precision, and big integers. It’s worth noting that this library is made out of big nums and rationals, so it tries to be exact when it can, but it can’t always, so it may not be accurate to call it exact real arithmetic. That’s why the title is “toward” real numbers and didn’t claim to be exact. And I’m curious whether you meant that exact real arithmetic is different in such a way that it would change either of the points that I made? Does it mean that performance is good enough that all languages should have it built in? Does it mean that approximation errors should then be considered the same as execution errors?