in reply to Re^8: Math::BigFloat to native double?
in thread Math::BigFloat to native double?

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.

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!

Replies are listed 'Best First'.
Re^10: Math::BigFloat to native double?
by syphilis (Archbishop) on Jul 14, 2015 at 03:45 UTC
    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));
}

    [download]
    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
[reply]
[d/l]
[select]

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

      #! perl -slw
use strict;
no warnings 'portable';
use Math::BigFloat;
use Data::Dump qw[ pp ];

my @lookup = map{ Math::BigFloat->new( "$_" ) } <DATA>; # pp \@lookup;

sub dd2dec {
    my( $hi, $lo ) = @_;
    my( $hiSign, $hiExp, $hiMant ) = unpack 'a1a11a52', unpack 'B64', 
+reverse pack 'd', $hi;
    $hiExp = unpack 'v', pack 'b11', $hiExp; print $hiExp;
    my $loMant = unpack 'x12a52', unpack 'B64', reverse pack 'd', $lo;
    print $hiMant, ' ', $loMant;
    my $dec = $lookup[ 0 ];
    substr( $hiMant, $_, 1 ) eq '1' and $dec += $lookup[ $_+1 ] for 0 
+.. 51;
    #$dec += $lookup[ 52 ];
    #substr( $loMant, $_, 1 ) eq '1' and $dec += $lookup[ $_+51 ] for 
+0 .. 51;
    $dec += 4;
    return $dec->bstr;
}

sub FP2bin{ sprintf "%s %35.17e", join( ' ', unpack 'a1a11a52', unpack
+ 'B64', reverse pack 'd', $_[0] ), $_[0]; }

sub i2dd {
    my $bf = Math::BigFloat->new( shift );
    my $hi = 0 + $bf->bstr;
    $bf -= Math::BigFloat->new( sprintf "%.17f", $hi );
    my $lo = 0 + $bf->bstr;
    return ( $hi, $lo );
}

sub d2Hex{
    my $fp = shift;
    my $bin = unpack 'Q', pack 'd', $fp;
    my( $sign, $exp, $mant ) = (
          ( ( $bin & 0x8000000000000000 ) ? '-' : '' ),
        ( ( ( $bin & 0x7FF0000000000000 ) >> 52 ) - 1023 ),
            ( $bin & 0x000FFFFFFFFFFFFF )
    );
    sprintf "%s0x1.%xp%d", $sign, $mant, $exp;
}

print join "\n", map{ FP2bin( $_ ) } i2dd( '3.141592653589793238462643
+3832795' );
print join "\n", map{ d2Hex( $_ ) } i2dd( '3.1415926535897932384626433
+832795' );

__DATA__
0.5
0.25
0.125
0.0625
0.03125
0.015625
0.0078125
0.00390625
0.001953125
0.0009765625
0.00048828125
0.000244140625
0.0001220703125
0.00006103515625
0.000030517578125
0.0000152587890625
0.00000762939453125
0.000003814697265625
0.0000019073486328125
0.00000095367431640625
0.000000476837158203125
0.0000002384185791015625
0.00000011920928955078125
0.000000059604644775390625
0.0000000298023223876953125
0.00000001490116119384765625
0.000000007450580596923828125
0.0000000037252902984619140625
0.00000000186264514923095703125
0.000000000931322574615478515625
0.0000000004656612873077392578125
0.00000000023283064365386962890625
0.000000000116415321826934814453125
0.0000000000582076609134674072265625
0.00000000002910383045673370361328125
0.000000000014551915228366851806640625
0.0000000000072759576141834259033203125
0.00000000000363797880709171295166015625
0.000000000001818989403545856475830078125
0.0000000000009094947017729282379150390625
0.00000000000045474735088646411895751953125
0.000000000000227373675443232059478759765625
0.0000000000001136868377216160297393798828125
0.00000000000005684341886080801486968994140625
0.000000000000028421709430404007434844970703125
0.0000000000000142108547152020037174224853515625
0.00000000000000710542735760100185871124267578125
0.000000000000003552713678800500929355621337890625
0.0000000000000017763568394002504646778106689453125
0.00000000000000088817841970012523233890533447265625
0.000000000000000444089209850062616169452667236328125
0.0000000000000002220446049250313080847263336181640625
0.00000000000000011102230246251565404236316680908203125
0.000000000000000055511151231257827021181583404541015625
0.0000000000000000277555756156289135105907917022705078125
0.00000000000000001387778780781445675529539585113525390625
0.000000000000000006938893903907228377647697925567626953125
0.0000000000000000034694469519536141888238489627838134765625
0.00000000000000000173472347597680709441192448139190673828125
0.000000000000000000867361737988403547205962240695953369140625
0.0000000000000000004336808689942017736029811203479766845703125
0.00000000000000000021684043449710088680149056017398834228515625
0.000000000000000000108420217248550443400745280086994171142578125
0.0000000000000000000542101086242752217003726400434970855712890625
0.00000000000000000002710505431213761085018632002174854278564453125
0.000000000000000000013552527156068805425093160010874271392822265625
0.0000000000000000000067762635780344027125465800054371356964111328125
0.00000000000000000000338813178901720135627329000271856784820556640625
0.00000000000000000000169406589450860067813664500135928392410278320312
+5
0.00000000000000000000084703294725430033906832250067964196205139160156
+25
0.00000000000000000000042351647362715016953416125033982098102569580078
+125
0.00000000000000000000021175823681357508476708062516991049051284790039
+0625
0.00000000000000000000010587911840678754238354031258495524525642395019
+53125
0.00000000000000000000005293955920339377119177015629247762262821197509
+765625
0.00000000000000000000002646977960169688559588507814623881131410598754
+8828125
0.00000000000000000000001323488980084844279794253907311940565705299377
+44140625
0.00000000000000000000000661744490042422139897126953655970282852649688
+720703125
0.00000000000000000000000330872245021211069948563476827985141426324844
+3603515625
0.00000000000000000000000165436122510605534974281738413992570713162422
+18017578125
0.00000000000000000000000082718061255302767487140869206996285356581211
+090087890625
0.00000000000000000000000041359030627651383743570434603498142678290605
+5450439453125
0.00000000000000000000000020679515313825691871785217301749071339145302
+77252197265625
0.00000000000000000000000010339757656912845935892608650874535669572651
+386260986328125
0.00000000000000000000000005169878828456422967946304325437267834786325
+6931304931640625
0.00000000000000000000000002584939414228211483973152162718633917393162
+84656524658203125
0.00000000000000000000000001292469707114105741986576081359316958696581
+423282623291015625
0.00000000000000000000000000646234853557052870993288040679658479348290
+7116413116455078125
0.00000000000000000000000000323117426778526435496644020339829239674145
+35582065582275390625
0.00000000000000000000000000161558713389263217748322010169914619837072
+677910327911376953125
0.00000000000000000000000000080779356694631608874161005084957309918536
+3389551639556884765625
0.00000000000000000000000000040389678347315804437080502542478654959268
+16947758197784423828125
0.00000000000000000000000000020194839173657902218540251271239327479634
+084738790988922119140625
0.00000000000000000000000000010097419586828951109270125635619663739817
+0423693954944610595703125
0.00000000000000000000000000005048709793414475554635062817809831869908
+52118469774723052978515625
0.00000000000000000000000000002524354896707237777317531408904915934954
+260592348873615264892578125
0.00000000000000000000000000001262177448353618888658765704452457967477
+1302961744368076324462890625
0.00000000000000000000000000000631088724176809444329382852226228983738
+56514808721840381622314453125
0.00000000000000000000000000000315544362088404722164691426113114491869
+282574043609201908111572265625
0.00000000000000000000000000000157772181044202361082345713056557245934
+6412870218046009540557861328125
0.00000000000000000000000000000078886090522101180541172856528278622967
+32064351090230047702789306640625
0.00000000000000000000000000000039443045261050590270586428264139311483
+660321755451150238513946533203125
0.00000000000000000000000000000019721522630525295135293214132069655741
+8301608777255751192569732666015625
0.00000000000000000000000000000009860761315262647567646607066034827870
+91508043886278755962848663330078125
0.00000000000000000000000000000004930380657631323783823303533017413935
+457540219431393779814243316650390625
0.00000000000000000000000000000002465190328815661891911651766508706967
+7287701097156968899071216583251953125
0.00000000000000000000000000000001232595164407830945955825883254353483
+86438505485784844495356082916259765625
0.00000000000000000000000000000000616297582203915472977912941627176741
+932192527428924222476780414581298828125
0.00000000000000000000000000000000308148791101957736488956470813588370
+9660962637144621112383902072906494140625
0.00000000000000000000000000000000154074395550978868244478235406794185
+48304813185723105561919510364532470703125
0.00000000000000000000000000000000077037197775489434122239117703397092
+741524065928615527809597551822662353515625
0.00000000000000000000000000000000038518598887744717061119558851698546
+3707620329643077639047987759113311767578125
0.00000000000000000000000000000000019259299443872358530559779425849273
+18538101648215388195239938795566558837890625
0.00000000000000000000000000000000009629649721936179265279889712924636
+592690508241076940976199693977832794189453125
0.00000000000000000000000000000000004814824860968089632639944856462318
+2963452541205384704880998469889163970947265625
0.00000000000000000000000000000000002407412430484044816319972428231159
+14817262706026923524404992349445819854736328125
0.00000000000000000000000000000000001203706215242022408159986214115579
+574086313530134617622024961747229099273681640625
0.00000000000000000000000000000000000601853107621011204079993107057789
+7870431567650673088110124808736145496368408203125
0.00000000000000000000000000000000000300926553810505602039996553528894
+89352157838253365440550624043680727481842041015625
0.00000000000000000000000000000000000150463276905252801019998276764447
+446760789191266827202753120218403637409210205078125
0.00000000000000000000000000000000000075231638452626400509999138382223
+7233803945956334136013765601092018187046051025390625
0.00000000000000000000000000000000000037615819226313200254999569191111
+86169019729781670680068828005460090935230255126953125
0.00000000000000000000000000000000000018807909613156600127499784595555
+930845098648908353400344140027300454676151275634765625
0.00000000000000000000000000000000000009403954806578300063749892297777
+9654225493244541767001720700136502273380756378173828125
0.00000000000000000000000000000000000004701977403289150031874946148888
+98271127466222708835008603500682511366903781890869140625
0.00000000000000000000000000000000000002350988701644575015937473074444
+491355637331113544175043017503412556834518909454345703125
0.00000000000000000000000000000000000001175494350822287507968736537222
+2456778186655567720875215087517062784172594547271728515625
0.00000000000000000000000000000000000000587747175411143753984368268611
+12283890933277838604376075437585313920862972736358642578125

      [download]

      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

      [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!
[reply]
[d/l]
[select]
        If we limit ourselves to Math::BigFloat, I just don't see any easy way of escaping the fact that, in i2dd(), Math::BigFloat->new( sprintf "%.17f", $hi ) is simply not a good enough base 10 approximation of $hi.

        For the given example, you're subtracting 3.1415926535897931000000000000000 from 3.1415926535897932384626433832795 in order to get the least significant double.
        But you need to be subtracting 3.1415926535897931159979634685442 which is a far more accurate base 10 approximation of 0x1.921fb54442d18p+1. That results in a value of 0.0000000000000001224646799147353, which has a hex representation of 0x1.1a62633145c06p-53. Correctly it would be 0x1.1a62633145c07p-53 - the discrepancy being due to the rounding done in converting to base 10 values for the calculations.

        In any case, the problem is that I can't see any simple way of coercing Math::BigFloat into arriving at more accurate values - as it apparently can't convert hex floats to Math::BigFloat values.

        All of which brings me back to using something like mpfr.
        AFAIK, my Math::MPFR ppm packages will work fine with your MSVC-built perls, but it has probably been a while since this has been properly tested.
        The ppd file specifies a couple of prerequisites to install, one of which (Math::Float128) may not work correctly for you. The other is Math::Decimal64.
        If you want to avoid installing those pre-requisite modules, just save a copy of my scratchpad in the cwd as Math-MPFR.ppd and run:
        ppm install Math-MPFR.ppd --force
        Otherwise you can run:
        ppm install http://www.sisyphusion.tk/ppm/Math-Decimal64.ppd --force
        ppm install http://www.sisyphusion.tk/ppm/Math-Float128.ppd --force
        ppm install http://www.sisyphusion.tk/ppm/Math-MPFR.ppd --force
        The prerequisites are needed only if you want to call a function that takes/returns a Math::Float128 or Math::Decimal64 object. (I don't foresee that you have any need to be calling those functions.)

        I fully understand and really don't mind at all if you don't want to go down that path - and I'm sure that other alternatives exist.
        But I'm pretty much out of ideas (and energy) if Math::MPFR is to be excluded. (Without it, there's just too many hoops for me).
        With Math::MPFR installed, sub i2dd becomes (eg): 
        sub i2dd {
  use Math::MPFR qw(:mpfr);
  my $prec = Rmpfr_get_default_prec();
  Rmpfr_set_default_prec(2098);
  my $val = Math::MPFR->new($_[0]);
  my $hi = Rmpfr_get_d($val, MPFR_RNDN);
  $val -= $hi;
  my $lo = Rmpfr_get_d($val, MPFR_RNDN);

  # Revert to original precision:
  Rmpfr_set_default_prec($prec);

  return($hi, $lo);
}

        [download]
        (Of course, the sub can be set up to operate more efficiently than as presented - I just wanted it to cover all angles.)

        Cheers,
        Rob
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom