[deleted]
Toward an API for the Real Numbers
81–85 of 85 posts
Re: Toward an API for the Real Numbers
#82Earlier quoted context omitted.
You can produce an arbitrary infinite stream using a random number generator, for instance.
The probability of generating any given infinite stream is 0, though.
But, assuming you have a true random number generator, so is the probability that a stream you generate is computable.
Re: Toward an API for the Real Numbers
#83The comments on that article are frustrating because they clearly didn't read it, by proposing that a rational type is sufficient.
"We solved this 40 years ago in SmallTalk!"
Re: Toward an API for the Real Numbers
#84Earlier quoted context omitted.
If these 3 lines of Python give you correct results... I keep wondering and never have this answered to my satisfaction: if so many people are just using floating point numbers in scientific calculations, and arguably even most scientists don't understand FP math any way better than the users of Android's Calculator app, then how many bad results are out there, that could be attributed to FP errors? Related: I don't…
It seems strange that they don't use a rational type, those are much easier for "normal" people to reason about. What you want would maybe be better as probability distributions (maybe parameterized with rational numbers)
Probability distributions are a related concepts, and I'd love to work with them as first-class objects. But just carrying the confidence intervals around would be a huge win; even ignoring the underlying distribution, it matters whether your result is 1.23 ± 0.0001, or 1.23 ± 20.
Re: Toward an API for the Real Numbers
#85Earlier quoted context omitted.
I disagree. IEEE 754 is a fantastic solution if you want a no-brainer plug-and-play approximation of the real numbers. Most people who complain really just want a rational number type.
Immaturity - it's the plague of our industry. The experts in floating point arithmetic, each having years of real-world experience, came together and hashed-out a standard embodying their collective experience. Yes, it's complicated. Yes, you need to learn it. No, you're highly unlikely to come up with anything better. Moreover, even if you did come up with something better it WILL have bugs, there WILL be edge cases…
A cultish devotion to "performance" and a refusal to revisit tradeoffs that were for hardware literally 10 million times slower than today's systems is the real plague of our industry. Yes, IEEE 754 was a towering technical achievement in its day (though its use is marred in practice by an industry that implemented only the most problematic of its rounding modes and ignored the trapping mode that should have been the default as soon as hardware performance improved a little), no-one's denying that. But it's got a lot of sharp edges (that were necessary at the time; indeed IEEE 754 makes significant performance compromises compared to e.g. Cray non-754 floating point modes) that a mature industry would not expose by default.