Re^9: Decimal Floating Point (DFP) and does Perl needs DFP?

I don't really know much about MPFR

It's good for reference - if you want to be assured of correctness in assignment, rounding and calculation. I've just now used it to demonstrate to myself that one cannot guarantee that either the "left-to-right" or "right-to-left" exponentiation calculations are going to be as (or more) accurate than performing the requisite number of multiplications.

The example I'll give is the calculation of 5.35 ** 107 - correct figure for which (to 15 decimal digits) is 8.58726126272004e77. Using double precision, the right-to-left method yields 8.58726126271995e77, left-to-right yields 8.58726126271996e77 and cumulatively multiplying 5.35 by itself 106 times yields 8.58726126271998e77 which is closest to the actual value.
(Both perl and mpfr are returning the same results.)

I.e. decimals are normally human made!

But it's those human made numbers that we're normally interested in. When I multiply (on a computer) A by B I'm generally not really interested in finding the product of the base 2 approximations of A and B.
I usually just want to know what A times B is.
And it would surely seem strange to aliens that our human made machines that we use to process our human made decimal numbers in fact don't process *those* numbers.
Doesn't seem strange to us of course - we're all well and truly accustomed to that just being a fact of life ;-)

Cheers,
Rob

Comment on Re^9: Decimal Floating Point (DFP) and does Perl needs DFP?

Replies are listed 'Best First'.
Re^10: Decimal Floating Point (DFP) and does Perl needs DFP? by LanX (Saint) on Jan 21, 2015 at 10:10 UTC
It's perfectly possible that a bad method sometimes returns a better result within the error margin. Only if you can show this behavior for a high percentage of random numbers it'll show that the error approximation is maybe wrong. Even then I wouldn't care much cause I needed a guaranteed result in affordable time for a pathological use case and NOT an optimal method.. :) The world of numerical algorithms is complex and probably ~40 mult operations is already too slow to be accepted. Chip designers prefer series expansions which can be easily wired as bit operations. Cheers Rolf PS: Je suis Charlie!	[reply]
Re^11: Decimal Floating Point (DFP) and does Perl needs DFP? by syphilis (Archbishop) on Jan 21, 2015 at 11:39 UTC
Even then I wouldn't care much ... Yeah, I'm not greatly fussed either. But it's something I haven't really thought much about, it's a bit interesting, and I haven't been looking at it quite right. I've only just now got my head around how to determine what the correct result for a**b (for integer b) is when rounding gets involved, and I don't mind elaborating if asked. Otherwise I'll shut up and leave it for a more appropriate forum. Cheers, Rob	[reply]
Re^12: Decimal Floating Point (DFP) and does Perl needs DFP? by BrowserUk (Patriarch) on Jan 21, 2015 at 11:48 UTC
don't mind elaborating if asked. Consider yourself asked :) With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked	[reply]
Re^13: Decimal Floating Point (DFP) and does Perl needs DFP? by syphilis (Archbishop) on Jan 22, 2015 at 13:12 UTC
Re^14: Decimal Floating Point (DFP) and does Perl needs DFP? by BrowserUk (Patriarch) on Jan 22, 2015 at 13:32 UTC
Re^12: Decimal Floating Point (DFP) and does Perl needs DFP? by LanX (Saint) on Jan 21, 2015 at 12:02 UTC
> Otherwise I'll shut up and leave it for a more appropriate forum. point is ... I only roughly remember my CS lessons on error propagation and I not very keen to open old books again. ... ;) If I had the time I would try to reproduce your results with Math::BigFloat cause I don't trust much into those C libraires. Please keep in mind a method can have a better error margin (ie worst case scenario) while an alternative approach is statistically far better (in the middle). it's even more complicated if you start discussing which input set of calculations should be considered representative for such a statistical investigation. for instance x*6e7 ... seriously? :P Cheers Rolf PS: Je suis Charlie!*	[reply]