Look, for years now you keep posting about floating point arithmetic and some obscure C libraries without even knowing the most basic terminology
Yes - computer arithmetic is something that interests me; last time I checked the gmp and mpfr libraries were a pre-requisite for building the gcc compiler and were used for its internal constant folding, but I agree that they haven't attained the widespread recognition they deserve; I think I'm ok with most of the jargon, but there's probably some holes there.
I think you should better stop embarrassing yourself and read the provided links
That's probably the most ridiculous piece of advice that I've ever received on this forum.
I have learned lots of useful and interesting things here simply by accepting that I might (as I sometimes do) embarrass myself.
(You might as well recommend that I stop breathing ;-)
So the last word is yours ...
Thank you.
I took issue with 2 things you said:
even if it's internal representation is flawed
and
part of arithmetic operations which accumulated rounding errors
You've explained the latter. You were using "rounding errors" in a narrower mathematical-jargon sense, but I took it in the broader general-English-usage sense (where an error is a mistake or fault).
I accept your explanation.
I don't think that I should be expected to have realized that you were using "rounding errors" in that mathematical sense, though others might argue differently (and they may well be right).
But you still haven't explained this notion of a "flawed internal representation". Just what is that ? Why is it flawed ? Maybe it's just another piece of basic terminology that I (as is to be expected) do not understand.
You can respond to that if you want ... though, IMO, there is no obligation upon you to do so.
The thing was, that your initial post gave me the impression you were saying that there are mistakes, faults and flaws in the way that floating point arithmetic is conducted.
I just wanted to point out that this is not so. (And that if such behaviour is found then it should be reported.)
I focused on those 2 particular phrases because they were the ones that were responsible for giving me that impression.
Cheers,
Rob
| [reply]
[d/l] |
| [reply] |
... but this is not a CS forum
++LanX
We've finally arrived at consensus ;-)
And I've no issue with your update to your original post:
Some simple rational numbers (e.g., 1/3 and 1/10) cannot be represented exactly in binary floating point, no matter what the precision is
Indeed ... and one of those two numbers you've quoted cannot even be represented exactly in decimal floating point, no matter what the precision is.
Software packages that perform rational arithmetic represent numbers as fractions with integral numerator and denominator, and can therefore represent any rational number exactly
Yes, and we already have rational arithmetic in perl in the form of Math::BigRat (which I don't recommend) and Math::GMPq (which I do recommend).
I've also recently had a bit of a look at raku's rational implementation and I think that it's pretty good. They don't provide the speed of Math::GMPq, but then they don't require that the gmp library be installed - whilst still providing an implementation that works reasonably quickly
The link that you provided (to https://en.wikipedia.org/wiki/Floating-point_arithmetic#Alternatives_to_floating-point_numbers) is an interesting read.
As I go through the various bullet points, I find that most of them are accommodated in perl.
I don't think perl covers "Logarithmic number systems" and "Tapered floating-point representation". (I'm not familiar with either of those ... something TODO.)
But I'm inclined to think that Math::GMPn (by salva), Math::GMPz, Math::GMPq, Math::MPFR and Math::MPFI (for the interval arithmetic) have the rest covered.
Interestingly, as regards the final bullet point in that section, the mpfr library has only recently gained the capability of evaluating (the given example of) sin(3*pi) exactly - so, with Math::MPFR, we can now do:
C:\>perl -MMath::MPFR=":mpfr" -E "$rop=Math::MPFR->new(); $op=Math::MP
+FR->new(3); $inex=Rmpfr_sinpi($rop, $op, MPFR_RNDN); say $inex; say $
+rop;"
0
0
Which gives us an exact evaluation of sin(3 * pi). (That $inex is 0 simply confirms that the result is exact. As you well know, such a result is impossible to achieve with rational arithmetic.)
At present, if you want to try out this particular feature, you'll need the current mpfr devel library and the current "devel" (ie github) Math-MPFR-4.17 module.
Cheers,
Rob | [reply]
[d/l]
[select] |
