Playing with DoubleDouble presicion

[HSE]

Hi all!

Last week we talk about rounding in FPU. Using REAL8 variables FPU results precision will be, close to sure, that of REAL8. Using REAL10 variables you can have more precision, but you don't know results precision. Then if you need more precision than REAL8 you have to use bignumbers systems.

Most of this systems are very slow because they must emulates the operations. A more faster system use a mix of FPU and software:

Double-double arithmetic
A common software technique to implement nearly quadruple precision using pairs of double-precision values is sometimes called double-double arithmetic.Using pairs of IEEE double-precision values with 53-bit significands, double-double arithmetic provides operations on numbers with significands of at least[4] 2 × 53 = 106 bits (actually 107 bits except for some of the largest values, due to the limited exponent range), only slightly less precise than the 113-bit significand of IEEE binary128 quadruple precision. The range of a double-double remains essentially the same as the double-precision format because the exponent has still 11 bits,[4] significantly lower than the 15-bit exponent of IEEE quadruple precision (a range of 1.8 × 10^308 for double-double versus 1.2 × 10^4932 for binary128).

I found a DoubleDouble. java file, from Martin Davis, with most important pieces and operations that can be translate to Masm.

Immutable, extended-precision floating-point numbers which maintain 106 bits
  (approximately 30 decimal digits) of precision.

Obviously I used a lot of macros, thinking in a future implementation. This is for ML64.

The test don't look so amazing  :

Code Select Expand

rr <3.14159265358979310e+000, 1.22464679914735320e-016>

rr <2.71828182845904510e+000, 1.44564689172925020e-016>

   3.1415926535897932384626433832795
+
   2.7182818284590452353602874713526
=
   5.8598744820488384738229308546321

Press any key to continue...


Regards, HSE.

a --------------  Real8x2.zip (15.43 kB - downloaded 8 times.)
b  - Corrected    toStandardNotation  Real8x2b.zip (15.85 kB - downloaded 8 times.)
     - Added         toSciNotation
c   strings problems look solved now

[jj2007]

 

I wonder how much precision is necessary to bring a spaceship safely to Mars. Any ideas?

[HSE]

I wonder how much precision is necessary to bring a spaceship safely to Mars. Any ideas?

Not so much, I think. In the end, you rely in sensors precision and jet correctors control.

Apollo used an italian calculator 

[Biterider]

Hi
Very clever. I only really understood it after reading this:

* A DoubleDouble uses a representation containing two double-precision values.
* A number x is represented as a pair of doubles, x.hi and x.lo, such that the
* number represented by x is x.hi + x.lo, where
*
* <pre>
*    |x.lo| <= 0.5*ulp(x.hi)
* </pre>
*
* and ulp(y) means "unit in the last place of y". The basic arithmetic
* operations are implemented using convenient properties of IEEE-754
* floating-point arithmetic.
* <p>

Biterider

[HSE]

Hi Biterider!

I only really understood it after reading this:

That is at DoubleDouble.inc end.

The .asm file was missing in the zip 

Thanks, HSE.

[Siekmanski]

I wonder how much precision is necessary to bring a spaceship safely to Mars. Any ideas?

Just enough. 

[hutch--]

 

Some good work there Hector, if I could think of a use (for myself) of higher levels of precision than 64 bit, I would probably use it but SSE2 64 bit maths has result lengths that generally require truncation to make it readable so I may be wasting such extra precision.

[jj2007]

I wonder how much precision is necessary to bring a spaceship safely to Mars.

I googled a bit and found this JPL/NASA article (October 2022): How Many Decimals of Pi Do We Really Need?

For JPL's highest accuracy calculations, which are for interplanetary navigation, we use 3.141592653589793.

For comparison, REAL10 precision: 3.141592653589793238. So the fpu is a factor 1000 more precise than the required precision for interplanetary travel.

[HSE]

if I could think of a use (for myself) of higher levels of precision than 64 bit..

If You think that, will be preciated like example.

[daydreamer]

 
Hitting Mars depends on if you put a chimpanzee or rocket scientist using computer to calculate trajectory between earth - Mars

None at all,just wait a few days and we all reach Mars 

Héctor about slow,Add/sub would be candidate for use packed SSE2

[HSE]

Hi daydreamer!

about slow,Add/sub would be candidate for use packed SSE2

Not even close!!

The reason why FPU can work at REAL8 precision is the existence of internal REAL10 to make operations.

SIMD don't have internal REAL10, then your precision probably is around a theoretical REAL6 (even if you are using REAL8 variables). You never can use SIMD if you want high precision.

Like Raymond remember us from time to time, rarely somebody need full REAL8 precision. Then SIMD frequently is a good and fast option. Not the case here.

HSE

[HSE]

Hi all!

Added translation of toSciNotation procedure.

Corrected toStandardNotation procedure from a mix of original and translation problems with negative exponents. Perhaps don't was never been called to much.

Update in first post.

HSE

[hutch--]

Hi Hector,

I have this sneaking suspicion that SSE2 and the old x87 FP share / use the same internal circuitry which would be a matter of economy in basic chip design for silicon area. Dual use is not uncommon in Intel hardware, MMX and FP sharing the same registers. I don't have a lot of use for it but 64 bit SSE2 seems to deliver about the same level of precision as any of the examples I have seen on the internet.

[jj2007]

The reason why FPU can work at REAL8 precision is the existence of internal REAL10 to make operations.

After finit, the fpu works internally and externally with REAL10 precision, i.e. you can load and save REAL10 numbers. That's 16 bits more precise than corresponding SIMD instructions, and most of the time equally fast. The only reason to go for SIMD is parallel (packed) processing, but that is not always possible.

[HSE]

64 bit SSE2 seems to deliver about the same level of precision as any of the examples I have seen on the internet.

For most applications even REAL4 is to much precision.

In some simulations calculating 1500 equations 8.5 millon times, using SSE take 75% of time using FPU, but with differences in results around 1/45000.

SSE have very few functions, you have to code them in software. Probably never that functions are coded to levels of precision close to FPU. That is obvious, if you need FPU precision you are going to use FPU, not SSE.

I think could be hard to find good at limit SSE-FPU precision comparisons, because people who need FPU, not even look at SSE 

It's not an interesting discussion because FPUs are everywhere. I have 8 FPU just in the phone