floating pt multiply..

floating pt multiply..

Post by t0n » Sat, 13 Dec 2003 22:54:39



confused a bit !
i am getting multiplication of two double precision nos
(got a random case)
a = 4086a8e1d3ea2ecc with
b = 4020c2940d63dc80 (in hex ieee)
as  40b7bc7333333333 on sparc(solaris)
and 40b7bc7333333332 on P-III(linux)
result with long double(128) on sparc was
400b7bc7333333332800e7aa32b60000
what's wrong with P-III ?
is it related to compiler? using gcc everywhere !

thanks a lot,
t0ny

 
 
 

floating pt multiply..

Post by Terje Mathise » Sat, 13 Dec 2003 23:41:31



> confused a bit !
> i am getting multiplication of two double precision nos
> (got a random case)
> a = 4086a8e1d3ea2ecc with
> b = 4020c2940d63dc80 (in hex ieee)
> as  40b7bc7333333333 on sparc(solaris)
> and 40b7bc7333333332 on P-III(linux)
> result with long double(128) on sparc was
> 400b7bc7333333332800e7aa32b60000
> what's wrong with P-III ?
> is it related to compiler? using gcc everywhere !

Wrong rounding mode? Or, since the result is really close to 0.5 ulp,
double rounding?

Terje

--

"almost all programming can be viewed as an exercise in caching"

 
 
 

floating pt multiply..

Post by Dik T. Winte » Sun, 14 Dec 2003 00:36:40



 > > confused a bit !
 > > i am getting multiplication of two double precision nos
 > > (got a random case)
 > > a = 4086a8e1d3ea2ecc with
 > > b = 4020c2940d63dc80 (in hex ieee)
 > > as  40b7bc7333333333 on sparc(solaris)
 > > and 40b7bc7333333332 on P-III(linux)
 > > result with long double(128) on sparc was
 > > 400b7bc7333333332800e7aa32b60000
 > > what's wrong with P-III ?
 > > is it related to compiler? using gcc everywhere !
 >
 > Wrong rounding mode? Or, since the result is really close to 0.5 ulp,
 > double rounding?

I suspect double rounding.  Most Intel systems use the 80-bit floating
point format and round back to double when storing the number.
--
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik/

 
 
 

floating pt multiply..

Post by Kevin Kreeg » Sun, 14 Dec 2003 09:20:33


This might explain a problem I am currently seeing.

In an application where we use lots of double precision math and have
some very touchy thresholds, if we compile with debug turned on and
low optimization we get a different results than with debug turned off
and high optimization.

Is it possible that, with super scalar processing, the order of
calculations between debug compile and high-optimization compile would
cause some values to be placed back into memory instead of being
stored in registers and thus round from 80 bits to 64 in a different
order with the two compiles?

We use P4 Xeon's and gcc on Linux.

-Kevin



> I suspect double rounding.  Most Intel systems use the 80-bit floating
> point format and round back to double when storing the number.

 
 
 

floating pt multiply..

Post by t0n » Sun, 14 Dec 2003 16:27:00


Quote:>  > Wrong rounding mode? Or, since the result is really close to 0.5 ulp,
>  > double rounding?
> I suspect double rounding.  Most Intel systems use the 80-bit floating
> point format and round back to double when storing the number.

hello,
thanks all :)
rounding mode was RN in all cases ..
(with RPINF it gives the result which is correct for RN on intel)

it appears it's double rounding at 80 and 64 bit ..
is it the only behaviour available with intel .. can it be avoided by setting
some bit in some register ? or .. is there any instruction ?

(meanwhile i was getting something else (rounded result was correct but in
long double something else) with power4 with AIX(32 bit mode)!
dont have results right now).

regards,
t0ny

 
 
 

floating pt multiply..

Post by Terje Mathise » Sun, 14 Dec 2003 20:44:36



> This might explain a problem I am currently seeing.

> In an application where we use lots of double precision math and have
> some very touchy thresholds, if we compile with debug turned on and
> low optimization we get a different results than with debug turned off
> and high optimization.

> Is it possible that, with super scalar processing, the order of
> calculations between debug compile and high-optimization compile would
> cause some values to be placed back into memory instead of being
> stored in registers and thus round from 80 bits to 64 in a different
> order with the two compiles?

> We use P4 Xeon's and gcc on Linux.

This is indeed _very_ likely.

However, setting the precision control bits to double will avoid nearly
all such "problems", except those that are caused by the extended
exponent range of x86:

In some case where a regular double would cause underflow, x86 will keep
a full precision mantissa until the value is stored to memory, when
double rounding will occur again.

OTOH, by doing everyting in extended precison, including "long double"
for all temporary/local variables, you are really getting significantly
more accurate results, they just won't be identical to a run-of-the-mill
cpu with simple double precision hw.

If the remaining difference is critical, try SSE2 on Pentium4: This is
an exact double precision engine, with the added benefit that you can
work with pairs of doubles in parallel if you want to.

Terje
--

"almost all programming can be viewed as an exercise in caching"

 
 
 

floating pt multiply..

Post by t0n » Sun, 14 Dec 2003 23:02:45


just saw fpu_control.h and wrote a control word 0x27f  setting precision cntrl to
_FPU_DOUBLE .. got the correct answer :)
are there any side effects of this, to other operations e.g. divide, sqrt ?

regards
t0ny

 
 
 

floating pt multiply..

Post by Terje Mathise » Mon, 15 Dec 2003 01:59:48



> just saw fpu_control.h and wrote a control word 0x27f  setting precision cntrl to
> _FPU_DOUBLE .. got the correct answer :)
> are there any side effects of this, to other operations e.g. divide, sqrt ?

All the IEEE operations (+-/*sqrt()) obey this, returning correctly
rounded double results directly, while the trancendental functions
always return full 80-bit results.

Adding 0.0 or multiplying by 1.0 would force a rounding operation.

Terje

--

"almost all programming can be viewed as an exercise in caching"

 
 
 

1. Floating Pt to Fixed Pt Algorithm?

|>
|> Hello, I just happened to run into this group which could hopefully answer a
|> question on real number conversion.
|>
|> I'd like to find a _very_ fast algorithm which converts floating point numbers
|> to fixed point using C/C++ at a binary level ( rather than strings ).  The reason
|> for being very fast is that I will have _mega_bytes of data to convert.
|>
|> If anyone knows of any general pseudocode algorithms or even ideas, please
|> e-mail me ( or post here ) if you can...
|>

Just use an union of your floating-point data type and and unsigned. Initialize
the floating-point part of the union with your data to convert and do the
comversion as:

        1/ get the exponent exp
        2/ substract the bias from the exponent (x7f for float, x3ff for double)
        3/ get the mantissa
        3'/ if implicit bit, add it to the mantissa
        4/ shift right the mantissa by (N - exp), where N is 23 for float, 52
           for double
        5/ add the sign

Following is a quick and dirty routine to convert from float to int, take it
just as an illustration of the above:

union thirty_two

  {
    float f;
    unsigned long l;
  };

long f2i (float x)

  {
    long mant;
    int exp, sign;
    union thirty_two fp32;
    fp32.f = x;
    /* get the sign */
    sign = fp32.l & 0x80000000;
    /* get the exponent */
    exp = (fp32.l >> 23) & 0xff;
    /* remove the bias */
    exp -= 0x7f;
    /* get the mantissa and make the implicit bit explicit */
    mant = fp32.l & 0x7fffff | 0x800000;
    /* convert the fixed point mantissa to an integer */
    mant >>= 23 - exp;
    /* fix the sign and return */
    return (sign) ? -mant : mant;
  }

There are many issues not addressed in this simple example:

        - overflow/underflow
        - rounding (the above routine truncates)

        Patrice.
--

        Patrice L. Roussel

2. DNIS Information on as5300/5800

3. seeking floating pt experiences with UT6R000

4. VMS to Unix advise

5. Accurate results from FP computation ( was IEEE Floating Pt )

6. Money OEM Version

7. conversion algorithm, floating pt formats

8. pine as mailer in opera

9. SH-4, Pentium/Celeron, PowerPC floating pt ops.

10. Rentrant Floating Pt. Libs?

11. how fixed pt multiplication is implemented

12. Life with TLB and no PT