Consider yourself asked :)

Heh ... you might be expecting something more erudite than what I can deliver :-)
I was getting bogged down in examining different approaches that were giving different results, and scratching my head over what was the right thing to do. And then it occurred to me that all I had to do was resort to some pretty basic clear thinking.
So there's nothing too profound here, and I'm really just admitting to a haziness that was probably afflicting no-one but myself.
Sticking to base 2 arithmetic for the moment, for a double precision value such as
5.34 or, in binary:
1.0101010111000010100011110101110000101000111101011100e2
raised to the integer power of (say) 100, there can be only one correct result - namely the result you get when you multiply the original value by itself 99 times, such that no rounding is performed (ie to 5300-bit precision), and then round that 5300-bit result back to 53 bits.
If you allow other results, then you admit to there being more than one correct answer - which would be to ask more of arithmetic than it is generally prepared to give.
The good "pow" algorithms won't follow that exact procedure of course, but that final 53-bit value is the value that they ought to return - and the value that does get returned by both perl (mostly) and mpfr for the various cases I've tested.
So ... for 5.34 ** 100, the result (as calculated by both mpfr_pow and the multiplication chain) came out at
1.1001101101000111011101111001101101001011101110000100e241 which equates to the 15 digit value of
5.67708900158395e72

And my perl-5.20.0 (NV is double), perl came up with the the identical value for 5.34 ** 100.
(However, in 35 of the 3000 test cases I ran, perl was out by 1 ULP - but that's not bad for perl.)

For decimal arithmetic, it's essentially the same scenario - the value returned for 1.00001 ** 6e7 should be the same as yielded by multiplying the decimal 1.000001 by itself 59999999 times (without any rounding being done) and then rounding it down to the appropriate precision.
Luckily, in practice you can usually do *some* rounding without jeopardising the accuracy of the final rounded-down result, and I'm sure that the good "pow" algorithms make full use of that potential - as did LanX's Math::BigFloat approach.

Cheers,
Rob

In reply to Re^13: Decimal Floating Point (DFP) and does Perl needs DFP? by syphilis
in thread Decimal Floating Point (DFP) and does Perl needs DFP? by flexvault

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.