Earlier 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.
Yes.
Toward an API for the Real Numbers
71–80 of 85 posts
Re: Toward an API for the Real Numbers
#72Earlier quoted context omitted.
> 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…
> 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.
Sure 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?
Re: Toward an API for the Real Numbers
#73Quote: "Operations complete in under a millisecond, not GFLOPS performance, but certainly good enough for many applications". Then you have a scientist reading this, wants it for research and then wonders why a simple 3 lines in Python code takes 3 days to complete. True story!
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)
Re: Toward an API for the Real Numbers
#74IEEE 754. If you're going to do any serious computation in floating point, serious meaning people's lives are going to depend on the outcome or a lot of money is on the line, then you MUST know what you're doing. We have standards in place so people can learn it, people creating math libraries can adhere to it, and those creating these kinds of applications can have confidence that things are going to work. I'm sorry…
> I'm sorry addition isn't commutative... My understanding is that in IEEE 754 compliant implementations of floating-point arithmetic, commutativity over "+" holds but not associativity. (With the possible exception to commutativity for the NaNs, though I don't remember offhand whether this caveat is necessary).
You are correct. It's associativity that doesn't hold, not commutativity. It really throws people off.
Re: Toward an API for the Real Numbers
#75Earlier quoted context omitted.
It's a lot more than "a few basic rules of the road". Why squander your attention budget on a numeric type with so many caveats and edge cases? What do you gain from it? If you actually need the performance of IEEE 754, then sure, use it, and have fun debugging all of the problems it has. But it's an extremely poor default for general-purpose programming.
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 that catch everyone by surprise. So instead of using a standard having 35 years worth of collective experience, whose edge cases are well-known, whose implementation is literally etched in silicon, and thousands upon thousands of libraries utilizing it - we'd rather start over and re-invent. That way we can spend the next 35 years uncovering a whole new and unknown set of issues. Sigh.
Re: Toward an API for the Real Numbers
#76Earlier quoted context omitted.
You need some way to cope with operations that don’t have real results for some values, such as log and sqrt of negative numbers
you can just represent those as a pair of real numbers, one for the real part, and one for the imaginary part. As long as you only (recursively) apply exponential and trig functions on those numbers, I believe you'll stay within the realm of complex numbers.
True, but I thought this was about real arithmetic not complex arithmetic
Re: Toward an API for the Real Numbers
#77Fun fact: The Boehm of this paper is the same Boehm as the garbage collector Exact Reals are an interesting topic. They go beyond fractions and and algebraic numbers by representing numbers as some kind of object that supports querying an arbitrary number of digits. This object may be a stream, generator, or function. There is some similarity between its implementation techniques and those of automatic differentiatio…
Simon Tatham has an exact real calculator called “spigot” https://www.chiark.greenend.org.uk/~sgtatham/spigot/
Re: Toward an API for the Real Numbers
#78Earlier quoted context omitted.
Why? Your operating system of choice lacks a proper calculator on your desktop PC?
Yes. I use gnome personally and macOS at work and both default calculators are not nearly as nice to use.
Then it's probably a good time to write one yourself. Or use wine to run the one from Windows.
Re: Toward an API for the Real Numbers
#79I am surprised not to see any mention of the numerical tower, used by some lisps. Did I just miss it?
Common Lisp and Scheme don’t have built-in support for exact real arithmetic
Re: Toward an API for the Real Numbers
#80I am surprised not to see any mention of the numerical tower, used by some lisps. Did I just miss it?
Common Lisp and Scheme don’t have built-in support for exact real arithmetic
Doesn't the nature of the tower mean you could add it in and it would just slow down computations that required it? I'm guessing the dynamic nature of the languages is the factor in leaning on?
That is, both have the surprise for most people that (/ 1 3) doesn't get rounded or truncated by default, due to the default of supporting rationals. You have to coerce into a floating point, right? Couldn't you do the same with exact reals? Put them at the top of the tower and maintain existing projections through the tower?
Edit:. Note that I don't think this precludes the algorithms here. Just that a type system that could use the tower could be augmented to get here. If that makes sense. Hence why I would think it would be mentioned. It is the expectations that things project in one direction that folks want? Right?