Re^8: Math::BigFloat to native double?

[syphilis]

I'll follow up as soon as I've double-checked

Ok ... I thought my perl script was printing out the decimal values to full precision, but it wasn't.

Corrected decimal representations are:

0x1.921fb54442d18p+1  => 3.1415926535897931
0x1.1a62633145c07p-53 => 1.2246467991473532e-16

They still don't add up to something near the original input value - but nor should they.
Whilst it's quite valid to simply add (concatenate) base 2 or base 16 values, if we want to add in base 10, we need to first convert those hex values to *106* bit precision decimal values.
Expressed as decimals to 106 bits of precision, I get:

0x1.921fb54442d18p+1  => 3.14159265358979311599796346854419
0x1.1a62633145c07p-53 => 1.2246467991473532071737640294584e-16

The sum of which is:
3.14159265358979323846264338327953
(This is the same as the input value, except for the extra "3" digit at the end.)

I was curious to see the actual hex values that Buk's script was producing so, on perl 5.22.0 (which provides "%a" formatting), I ran:

use Math::BigFloat;;

$n = Math::BigFloat->new( '3.1415926535897932384626433832795' );;

$d = 0 + $n->bstr;;

printf "%.17f\n", $d;;
printf "%a\n", $d;;

$bfd = Math::BigFloat->new( sprintf "%.17f", $d );;
print $bfd;;

$n -= $bfd;;
print $n;;
printf "%a\n", $n;;

which outputs (when run with the "-l" switch):

3.14159265358979310
0x1.921fb54442d18p+1
3.1415926535897931
0.0000000000000001384626433832795
0x1.3f45eb146ba31p-53

So the most significant double agrees with my ppc box, but the value of the least significant double differs.
Not so sure that splitting the values on the basis of the Math::BigFloat values can provide correct 106-bit values.

Cheers,
Rob

[BrowserUk]

They still don't add up to something near the original input value - but nor should they. ... if we want to add in base 10, we need to first convert those hex values to *106* bit precision decimal values.

Okay. That makes no sense to me at all.

Given this comes from you, and is math, I pretty much know I'm wrong here. But ...

And now I'm wondering if your hardware double-double implementation is the same thing as the double-double I was referring to.

Which in summary, uses pairs of doubles, to achieve greater precision by splitting the values into two parts and storing the hi part and the lo part in the pair. Thus, when the two parts are added together, they form the complete value.

Now, the two parts cannot have more than 53-bits of precision each; so the idea that "if we want to add in base 10, we need to first convert those hex values to *106* bit precision decimal values." doesn't make sense to me.

Where does the extra precision for each of the two values, before combining them, come from?

Half of my brain is saying: this is the classic binary representation of decimal values thing; but in reverse.

Not so sure that splitting the values on the basis of the Math::BigFloat values can provide correct 106-bit values

And the other half is saying: M::BF may not be the fastest thing in the arbitrary precision world; but it is arbitrary precision, so surely when it gets there, the results are accurate?

By now you're probably slapping your forehead saying: "Why doesn't he just install Math::MPFR!"

And the answer is, I don't want an arbitrary precision or multi-precision library. I'm only using M::BF because it was on my machine and a convenient (I thought) way to test a couple of things to do with my own implementation of the double-double thing (per the paper I linked).

One of which is to write my own routines for outputting in hex-float format (done) and converting to decimal. I was working on the latter when I need to generate the binary decimal constants and here I am.

So why not just use someone else's library?

1. My aversion to incorporating the kitchen sink when all I need is the plug.

   MFPR probably requires half dozen other libraries, all of which are probably monolithic monsters in their own right; and almost certainly won't compile using MSVC.

   I know you probably provide a PPM at your repository; but will it work with the version of MSVC I using. Probably not.

   So why not upgrade to a later version? Because the only version now available from MS won't install on Vista. So why not upgrade from Vista? Because it costs money. I probably will when I upgrade my motherboard and cpu sometime next year.

   So why not just use MingW? Because my clients don't use that; and because I don't like it.

2. Ultimately, the intent is to convert the add, subtract and multiply routines that I need to assembler.

   Using, if and where possible, whatever MMX or SIMD instructions lend themselves to the purpose.

   The routines will be called from (Inline) C as the current double implementation is.

   The desire is to first get more precision (hence double-double), then more speed, by attempting to apply SIMD multiply-add to whole scan-lines of the mandelbrot set that are the background to all of this.

   So, ultimately, I don't need a Perl library (Math::MPFR); don't want the agony of trying build OSS libraries using MSVC; and won't achieve my goal by adding some huge pile of (clever) but (if typical of the breed) macro-hell, unintelligible code to my project.

3. Finally, I'm obviously not understanding the subtleties of the way the restrictions of the machine representations are affecting the math.

   I mean; how hard can it be to add two numbers together, right. And yet; here I am struggling to understand how to add two numbers together.

   And that is all the reason -- and possibly the best reason -- for persisting in my goal of writing my own implementation of the double-double representation.

Oooh! I feel so much better for having got that off my chest :) I realise that I've probably lost your patronage for my endeavour in the process; but so be it.

[syphilis]

That makes no sense to me at all

It was a poorly expressed explanation.
The most significant double is 0x1.921fb54442d18p+1. (We agree on this, at least.)
That string expresses an exact value, but 3.1415926535897931 is only a very poor approximation of that exact value.
The least significant double is, according to me, 0x1.1a62633145c07p-53.
That string expresses an exact value, but 1.2246467991473532e-16 is only a very poor approximation of that exact value.
So ... my doubledouble contains a value that is exactly the sum of both:
0x1.921fb54442d18p+1 + 0x1.1a62633145c07p-53
But you can't expect the sum of the 2 rough decimal approximations to be equivalent to the exact hex sum of the 2 hex numbers. (And it's not, of course.)

The least significant double that your approach came up with was 0x1.3f45eb146ba31p-53.
Your decimal approximation of that exact value is 0.0000000000000001384626433832795.
When you add your 2 decimal approximations together you end up with the input value - but that's false comfort.
The actual value contained by your doubledouble is, according to the way I look at them, is not really the sum of the 2 decimal approximations - it's the sum of the 2 hex values:
0x1.921fb54442d18p+1 + 0x1.3f45eb146ba31p-53.
That corresponds to a base 10 value of 3.141592653589793254460606851823683 (which differs significantly from the input).
Your doubledouble, expressed in base 2 is:
11.001001000011111101101010100010001000010110100011000010011111101000101111010110001010001101011101000110001
which is not the correct 107 bit representation of the input value.
If you use that doubledouble as your pi approximation, then you'll only get incorrect results.

FWIW, if I want to calculate the double-double representation of a specific value, I do essentially the same as you, except that I use Math::MPFR instead of Math::BigFloat.
And I set precision to 2098 bits. I have:

# sub dd_str takes a string as its arg and returns
# the 2 doubles that form the doubledouble.
# Works correctly if default Math::MPFR precision is
# 2098 bits - else might return incorrect values.
sub dd_str {

  # Set $val to the 2098 bit representation of $_[0] 
  my $val = Math::MPFR->new($_[0]);

  # Most significant double is $val converted to a
  # double, rounding to nearest with ties to even
  my $msd = Rmpfr_get_d($val, MPFR_RNDN);

  $val -= $msd;

  # Least siginificant double is $val converted
  # to a double.
  return ($msd, Rmpfr_get_d($val, MPFR_RNDN));
}

2098 bits is overkill for the vast majority of conversions. It stems from the fact that the doubledouble can accurately represent certain values up to (but not exceeding) 2098 bits.
For example, on my PPC box I can assign  $x = (2 **1023) + (2 ** -1074); and the doubledouble $x will consist of the 2 doubles 2**1023 and 2**-1074, thereby accurately representing that 2098 bit value.
The value of this capability is limited - multiply $x by (say) 1.01 and all of that additional precision is lost. The result is the same as multiplying 2**1023 by 1.01.

Anyway ... first question is "how to set your doubledouble pi correctly using Math::BigFloat ?".

I couldn't quickly come up with an answer, but I'll give it some more thought later on today.

Cheers,
Rob

[BrowserUk]

This is what I have so far for my input/output routines:

<Reveal this spoiler or all in this thread>

The names don't make much sense at the moment but

1. dd2Dec() is intended to convert a doubledouble to decimal.

   Not Working yet.

   I produced the set of constant in __DATA__ using M::BF with div_scale set 100.

2. FP2bin() just dumps the contents of a double as binary fields.
3. i2dd() takes string and uses M::BF to split it to a pair of doubles.

   Seems to work (for pi); but I'm conscious of your statements above.

4. d2Hex() double to hex notation.

And this is the output from the above and the decimal calculation that appears to show it works:

C:\test>ddt
0 10000000000 1001001000011111101101010100010001000010110100011000    
+        3.14159265358979310e+000
0 01111001010 0011111101000101111010110001010001101011101000110001    
+        1.38462643383279500e-016
0x1.921fb54442d18p1
0x1.3f45eb146ba31p-53 

3.1415926535897931000000000000000
0.0000000000000001384626433832795
3.1415926535897932384626433832795 Calculated
3.1415926535897932384626433832795 Input