0
Answered

How is a double precision number extended?

kuanxu33 1 month ago updated 4 weeks ago 2
>> mp(1/3)            % Accuracy is limited to double precision
ans =                 % since 1/3 was evaluated in double precision first
    0.33333333333333331482961625624739099293947219848633

How are the extended digits, i.e. 1482961625624739099293947219848633, created? Are they totally random numbers or some of them are determined by the guard digits in the double-precision representation of 1/3?


I've been thinking that a natural extension would be done by trailing zeros, resulting, for example, in the example above, something like:

0.333333333333333300000000000000000000000000000000

Any discussion/comment is welcome. Thanks!

Answer

Answer
Answered

Toolbox uses binary representation of floating-point numbers

When we extend double precision number with zeroes (in binary representation) - it doesn't refer to zeros in decimal representation (please refer to some guides on floating-point numbers & their formats for deeper understanding).

Do not use mp(1/3) because 1/3 is computed in double precision and then converted to quadruple - final value has double precision accuracy (not the intended quadruple).

The correct way to compute constants to full accuracy is:

>> mp.Digits(34);
>> mp('1/3')
ans = 
    0.3333333333333333333333333333333333   

>> mp.Digits(50);
>> mp('1/3')
ans = 

    0.33333333333333333333333333333333333333333333333333

>> mp.Digits(70);
>> mp('1/3')

ans = 

    0.3333333333333333333333333333333333333333333333333333333333333333333333

In this case, double precision constant is not extended by zeros (in binary format) but computed with full accuracy from the onset (within limits of specified precision).

***

Could you please reply to another thread you started yesterday: https://mct.userecho.com/communities/1/topics/179-it-would-be-fantastic-if-quadeig-is-supported


We prioritize only well-motivated requests to add new functionality.

Answer
Answered

Toolbox uses binary representation of floating-point numbers

When we extend double precision number with zeroes (in binary representation) - it doesn't refer to zeros in decimal representation (please refer to some guides on floating-point numbers & their formats for deeper understanding).

Do not use mp(1/3) because 1/3 is computed in double precision and then converted to quadruple - final value has double precision accuracy (not the intended quadruple).

The correct way to compute constants to full accuracy is:

>> mp.Digits(34);
>> mp('1/3')
ans = 
    0.3333333333333333333333333333333333   

>> mp.Digits(50);
>> mp('1/3')
ans = 

    0.33333333333333333333333333333333333333333333333333

>> mp.Digits(70);
>> mp('1/3')

ans = 

    0.3333333333333333333333333333333333333333333333333333333333333333333333

In this case, double precision constant is not extended by zeros (in binary format) but computed with full accuracy from the onset (within limits of specified precision).

***

Could you please reply to another thread you started yesterday: https://mct.userecho.com/communities/1/topics/179-it-would-be-fantastic-if-quadeig-is-supported


We prioritize only well-motivated requests to add new functionality.

Thanks for the hint, buddy. The fact that the zero-padding takes place in the binary format instead of decimal totally slipped off my mind. Again, really appreciate!