the 2 doubles would there round out as 3.14159265358979e+000 and 1.22464679914735e-016

But?

3.14159265358979e+000 
0.000000000000000122464679914735
3.141592653589790122464679914735
[download]

Something is not right.

Update: for example:

0.1 1001 0010 0001 1111 1011 0101 0100 0100 0100 0010 1101 0001 1000  
+ 0 1 0001 1010 0110 0010 0110 0011 0011 0001 0100 0101 1100 0000 0111
+ E2
  1    9    2    1    f    b    5    4    4    4    2    d    1    8  
+ ? 1    1    a    6    2   6     3    3    1    4    5    c    0    7
[download]

Something is not right

Yeah - my hex values are correct, but their decimal approximations look decidedly suspect.
(I'll follow up as soon as I've double-checked.)

Cheers,
Rob

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
[download]

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
[download]

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;;
[download]

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

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

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

This is what I get by adding up all the binary fractions for all the set bits in your hex/binary representation:

 0  0.50000000000000000000000000000000000000000000000000
 1  0.25000000000000000000000000000000000000000000000000
 4  0.03125000000000000000000000000000000000000000000000
 7  0.00390625000000000000000000000000000000000000000000
 12 0.00012207031250000000000000000000000000000000000000
 13 0.00006103515625000000000000000000000000000000000000
 14 0.00003051757812500000000000000000000000000000000000
 15 0.00001525878906250000000000000000000000000000000000
 16 0.00000762939453125000000000000000000000000000000000
 17 0.00000381469726562500000000000000000000000000000000
 19 0.00000095367431640625000000000000000000000000000000
 20 0.00000047683715820312500000000000000000000000000000
 22 0.00000011920928955078125000000000000000000000000000
 24 0.00000002980232238769531300000000000000000000000000
 26 0.00000000745058059692382810000000000000000000000000
 30 0.00000000046566128730773926000000000000000000000000
 34 0.00000000002910383045673370400000000000000000000000
 39 0.00000000000090949470177292824000000000000000000000
 41 0.00000000000022737367544323206000000000000000000000
 42 0.00000000000011368683772161603000000000000000000000
 44 0.00000000000002842170943040400700000000000000000000
 48 0.00000000000000177635683940025050000000000000000000
 49 0.00000000000000088817841970012523000000000000000000
 54 0.00000000000000002775557561562891400000000000000000
 58 0.00000000000000000173472347597680710000000000000000
 59 0.00000000000000000086736173798840355000000000000000
 61 0.00000000000000000021684043449710089000000000000000
 64 0.00000000000000000002710505431213761100000000000000
 65 0.00000000000000000001355252715606880500000000000000
 69 0.00000000000000000000084703294725430034000000000000
 72 0.00000000000000000000010587911840678754000000000000
 73 0.00000000000000000000005293955920339377100000000000
 77 0.00000000000000000000000330872245021211070000000000
 78 0.00000000000000000000000165436122510605530000000000
 81 0.00000000000000000000000020679515313825692000000000
 82 0.00000000000000000000000010339757656912846000000000
 86 0.00000000000000000000000000646234853557052870000000
 88 0.00000000000000000000000000161558713389263220000000
 92 0.00000000000000000000000000010097419586828951000000
 94 0.00000000000000000000000000002524354896707237800000
 95 0.00000000000000000000000000001262177448353618900000
 96 0.00000000000000000000000000000631088724176809440000
104 0.00000000000000000000000000000002465190328815661900
105 0.00000000000000000000000000000001232595164407830900
106 0.00000000000000000000000000000000616297582203915470
    0.78539816439944831161566131939647068003696135548270 <<< 
      001124476675678989811791619118619999856552441020
                         00  0 0 01  0

    0.78539816439944831161566131939647068003696135548270
  * 4                                                   
  = 3.14159265759779324646264527758588272014784542193080
    3.1415926535897932384626433832795 <<<<<<<<<<<<<<<<<<<< (my) origin
+al input.
              ^ ^^    ^^     ^^^^^^^^
[download]

---

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".

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!