How is a double precision number extended?
>> 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
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!
Customer support service by UserEcho
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:
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.