floating point problem

floating point problem

Post by Rigo Schult » Sat, 21 Jun 2003 01:32:33



I try to run some simulations at different hardware architectures, ALPHA
  EV6 and x86. Both runnig Linux.
But I get Floating Point Exceptions at the Alpha system.
It seems that the "float" and "double" range on EV6 are different to the
x86 systems. Sorry, I'm not familar with that stuff.
Here is a short c-source, that shows the difference. But I do'nt
understand why the Alpha breaks too early.

Thanks Rigo

#include <stdio.h>

int main(void)
{
     enum {N = 150};
     int i;
     float under = 1.0;  /* for underflow */
     float over = 1.0;  /* for overflow */
     printf ("sizeof(int) = %d\n", sizeof(int));
     printf ("sizeof(float) = %d\n", sizeof(float));
     printf ("sizeof(double) = %d\n", sizeof(double));
     printf ("sizeof(long double) = %d\n", sizeof(long double));
     printf ("\n\n");
     printf("\t i   under            over      \n");
     printf("\t--------------------------------\n");
     for (i = 1; i <= N; ++i) {
        under /= 2.0;
        over *= 2.0;
        printf("\t %d   %e   %e\n", i, under, over);
     }
     return (0);

Quote:}

 
 
 

floating point problem

Post by Falk Hueffne » Sat, 21 Jun 2003 01:39:26



> It seems that the "float" and "double" range on EV6 are different to
> the x86 systems. Sorry, I'm not familar with that stuff.

x86 might use 80 bit for some double operation, since that is what the
FPU provides.

Quote:> Here is a short c-source, that shows the difference. But I do'nt
> understand why the Alpha breaks too early.

I don't quite understand your question... What's happening is that you
do arithmetic with a denormalized number, which traps by default on
Alpha, since it isn't 100% IEEE-compliant. Is that what you wanted to
know?

--
        Falk

 
 
 

floating point problem

Post by Robert M. Riches J » Sat, 21 Jun 2003 03:42:04




>> It seems that the "float" and "double" range on EV6 are different to
>> the x86 systems. Sorry, I'm not familar with that stuff.

> x86 might use 80 bit for some double operation, since that is what the
> FPU provides.

>> Here is a short c-source, that shows the difference. But I do'nt
>> understand why the Alpha breaks too early.

> I don't quite understand your question... What's happening is that you
> do arithmetic with a denormalized number, which traps by default on
> Alpha, since it isn't 100% IEEE-compliant. Is that what you wanted to
> know?

For many of these problems, the solution is to add the
-mieee option to the compile command.  This has made a big
difference for me on several packages.

Good luck.

Robert Riches

(Yes, that is one of my email addresses.)

 
 
 

floating point problem

Post by Rigo Schult » Sat, 21 Jun 2003 16:36:18



Quote:> For many of these problems, the solution is to add the
> -mieee option to the compile command.  This has made a big
> difference for me on several packages.

-mieee works quite good. but i get wrong results.

#include <stdio.h>

int main(void)
{
     float check;
     check = 5.877472e-39 / 2.0;
     printf("Check: %e \n", check);
     return (0);

Quote:}

on x86:>Check: 2.938736e-39
on alpha:>Check: 5.562685e-309

It's only a little bit different :o(

thanks

 
 
 

floating point problem

Post by Falk Hueffne » Sat, 21 Jun 2003 16:53:39



> -mieee works quite good. but i get wrong results.

>      check = 5.877472e-39 / 2.0;

> on x86:>Check: 2.938736e-39
> on alpha:>Check: 5.562685e-309

That's an underflow. On Alpha, FLT_MIN is 1.175494e-38, and DBL_MIN
2.225074e-308. So you should probably use double.

Note also that -mieee will incur a noticeable slowdown on models prior
to EV6 (and a horrendous slowdown if denormals actually occur, since
the kernel will emulate them).

--
        Falk

 
 
 

floating point problem

Post by Rigo Schult » Sat, 21 Jun 2003 17:25:42




>>-mieee works quite good. but i get wrong results.

>>     check = 5.877472e-39 / 2.0;

>>on x86:>Check: 2.938736e-39
>>on alpha:>Check: 5.562685e-309

> That's an underflow. On Alpha, FLT_MIN is 1.175494e-38, and DBL_MIN
> 2.225074e-308. So you should probably use double.

> Note also that -mieee will incur a noticeable slowdown on models prior
> to EV6 (and a horrendous slowdown if denormals actually occur, since
> the kernel will emulate them).

Thank you for your quick answer.
It's quiet sad thought alpha FPU is much better than x86 stuff.
 
 
 

floating point problem

Post by Rigo Schult » Sat, 21 Jun 2003 03:32:00


(CHARSET: PC-8)
(PATH: 263/950 236/150 261/38 140/1 106/2000 123/500 3613/1275 134/10)

I try to run some simulations at different hardware architectures, ALPHA
  EV6 and x86. Both runnig Linux.
But I get Floating Point Exceptions at the Alpha system. It seems that the
"float" and "double" range on EV6 are different to the x86 systems. Sorry,
I'm not familar with that stuff. Here is a short c-source, that shows the
difference. But I do'nt understand why the Alpha breaks too early.

Thanks Rigo

#include <stdio.h>

int main(void)
{
     enum {N = 150};
     int i;
     float under = 1.0;  /* for underflow */
     float over = 1.0;  /* for overflow */
     printf ("sizeof(int) = %d\n", sizeof(int));
     printf ("sizeof(float) = %d\n", sizeof(float));
     printf ("sizeof(double) = %d\n", sizeof(double));
     printf ("sizeof(long double) = %d\n", sizeof(long double));
     printf ("\n\n");
     printf("\t i   under            over      \n");
     printf("\t--------------------------------\n");
     for (i = 1; i <= N; ++i) {
        under /= 2.0;
        over *= 2.0;
        printf("\t %d   %e   %e\n", i, under, over);
     }
     return (0);

Quote:}

--- BBBS/NT v4.01 Flag-5
 * Origin: TCOB1: A slice of life on your plate (2:263/950)

--
This message posted from Shurato's Heavenly Sphere Telnet BBS
telnet://shurato.darktech.org

Shurato:  Admin of SHS.

 
 
 

floating point problem

Post by Falk Hueffne » Sat, 21 Jun 2003 03:39:00


(CHARSET: PC-8)
(PATH: 263/950 236/150 261/38 140/1 106/2000 123/500 3613/1275 134/10)


> It seems that the "float" and "double" range on EV6 are different to
> the x86 systems. Sorry, I'm not familar with that stuff.

x86 might use 80 bit for some double operation, since that is what the FPU
provides.

Quote:> Here is a short c-source, that shows the difference. But I do'nt
> understand why the Alpha breaks too early.

I don't quite understand your question... What's happening is that you do
arithmetic with a denormalized number, which traps by default on Alpha, since
it isn't 100% IEEE-compliant. Is that what you wanted to know?

--
        Falk

--- BBBS/NT v4.01 Flag-5
 * Origin: TCOB1: A slice of life on your plate (2:263/950)

--
This message posted from Shurato's Heavenly Sphere Telnet BBS
telnet://shurato.darktech.org

Shurato:  Admin of SHS.

 
 
 

floating point problem

Post by Robert M. Riches J » Sat, 21 Jun 2003 03:42:00


(CHARSET: PC-8)
(PATH: 263/950 236/150 261/38 140/1 106/2000 123/500 3613/1275 134/10)



>> It seems that the "float" and "double" range on EV6 are different to
>> the x86 systems. Sorry, I'm not familar with that stuff.

> x86 might use 80 bit for some double operation, since that is what the
> FPU provides.

>> Here is a short c-source, that shows the difference. But I do'nt
>> understand why the Alpha breaks too early.

> I don't quite understand your question... What's happening is that you
> do arithmetic with a denormalized number, which traps by default on
> Alpha, since it isn't 100% IEEE-compliant. Is that what you wanted to
> know?

For many of these problems, the solution is to add the
-mieee option to the compile command.  This has made a big
difference for me on several packages.

Good luck.

Robert Riches

(Yes, that is one of my email addresses.)

--- BBBS/NT v4.01 Flag-5
 * Origin: TCOB1: A slice of life on your plate (2:263/950)

--
This message posted from Shurato's Heavenly Sphere Telnet BBS
telnet://shurato.darktech.org

Shurato:  Admin of SHS.

 
 
 

floating point problem

Post by Rigo Schult » Sat, 21 Jun 2003 18:36:00


(CHARSET: PC-8)
(PATH: 263/950 236/150 261/38 140/1 106/2000 123/500 3613/1275 134/10)


Quote:> For many of these problems, the solution is to add the
> -mieee option to the compile command.  This has made a big
> difference for me on several packages.

-mieee works quite good. but i get wrong results.

#include <stdio.h>

int main(void)
{
     float check;
     check = 5.877472e-39 / 2.0;
     printf("Check: %e \n", check);
     return (0);

Quote:}

on x86:>Check: 2.938736e-39
on alpha:>Check: 5.562685e-309

It's only a little bit different :o(

thanks

--- BBBS/NT v4.01 Flag-5
 * Origin: TCOB1: A slice of life on your plate (2:263/950)

--
This message posted from Shurato's Heavenly Sphere Telnet BBS
telnet://shurato.darktech.org

Shurato:  Admin of SHS.

 
 
 

floating point problem

Post by Falk Hueffne » Sat, 21 Jun 2003 18:53:00


(CHARSET: PC-8)
(PATH: 263/950 236/150 261/38 140/1 106/2000 123/500 3613/1275 134/10)


> -mieee works quite good. but i get wrong results.

>      check = 5.877472e-39 / 2.0;

> on x86:>Check: 2.938736e-39
> on alpha:>Check: 5.562685e-309

That's an underflow. On Alpha, FLT_MIN is 1.175494e-38, and DBL_MIN
2.225074e-308. So you should probably use double.

Note also that -mieee will incur a noticeable slowdown on models prior to EV6
(and a horrendous slowdown if denormals actually occur, since the kernel will
emulate them).

--
        Falk

--- BBBS/NT v4.01 Flag-5
 * Origin: TCOB1: A slice of life on your plate (2:263/950)

--
This message posted from Shurato's Heavenly Sphere Telnet BBS
telnet://shurato.darktech.org

Shurato:  Admin of SHS.

 
 
 

floating point problem

Post by Rigo Schult » Sat, 21 Jun 2003 19:25:00


(CHARSET: PC-8)
(PATH: 263/950 236/150 261/38 140/1 106/2000 123/500 3613/1275 134/10)



>>-mieee works quite good. but i get wrong results.

>>     check = 5.877472e-39 / 2.0;

>>on x86:>Check: 2.938736e-39
>>on alpha:>Check: 5.562685e-309

> That's an underflow. On Alpha, FLT_MIN is 1.175494e-38, and DBL_MIN
> 2.225074e-308. So you should probably use double.

> Note also that -mieee will incur a noticeable slowdown on models prior
> to EV6 (and a horrendous slowdown if denormals actually occur, since
> the kernel will emulate them).

Thank you for your quick answer.
It's quiet sad thought alpha FPU is much better than x86 stuff.

--- BBBS/NT v4.01 Flag-5
 * Origin: TCOB1: A slice of life on your plate (2:263/950)

--
This message posted from Shurato's Heavenly Sphere Telnet BBS
telnet://shurato.darktech.org

Shurato:  Admin of SHS.

 
 
 

floating point problem

Post by Rigo Schult » Sat, 21 Jun 2003 03:32:00


(CHARSET: PC-8)
(PATH: 263/950 236/150 261/38 140/1 106/2000 123/500 3613/1275 134/10)

(CHARSET: PC-8)
(PATH: 263/950 236/150 261/38 140/1 106/2000 123/500 3613/1275 134/10) From:

I try to run some simulations at different hardware architectures, ALPHA
  EV6 and x86. Both runnig Linux.
But I get Floating Point Exceptions at the Alpha system. It seems that the
"float" and "double" range on EV6 are different to the x86 systems. Sorry,
I'm not familar with that stuff. Here is a short c-source, that shows the
difference. But I do'nt understand why the Alpha breaks too early.

Thanks Rigo

#include <stdio.h>

int main(void)
{
     enum {N = 150};
     int i;
     float under = 1.0;  /* for underflow */
     float over = 1.0;  /* for overflow */
     printf ("sizeof(int) = %d\n", sizeof(int));
     printf ("sizeof(float) = %d\n", sizeof(float));
     printf ("sizeof(double) = %d\n", sizeof(double));
     printf ("sizeof(long double) = %d\n", sizeof(long double));
     printf ("\n\n");
     printf("\t i   under            over      \n");
     printf("\t--------------------------------\n");
     for (i = 1; i <= N; ++i) {
        under /= 2.0;
        over *= 2.0;
        printf("\t %d   %e   %e\n", i, under, over);
     }
     return (0);

Quote:}

-+- BBBS/NT v4.01 Flag-5
 + Origin: TCOB1: A slice of life on your plate (2:263/950)

--
This message posted from Shurato's Heavenly Sphere Telnet BBS
telnet://shurato.darktech.org

Admin of SHS.

--- BBBS/NT v4.01 Flag-5
 * Origin: TCOB1: A slice of life on your plate (2:263/950)

--
This message posted from Shurato's Heavenly Sphere Telnet BBS
telnet://shurato.darktech.org

Shurato:  Admin of SHS.

 
 
 

floating point problem

Post by Falk Hueffne » Sat, 21 Jun 2003 03:39:00


(CHARSET: PC-8)
(PATH: 263/950 236/150 261/38 140/1 106/2000 123/500 3613/1275 134/10)

(CHARSET: PC-8)
(PATH: 263/950 236/150 261/38 140/1 106/2000 123/500 3613/1275 134/10) From:


> It seems that the "float" and "double" range on EV6 are different to
> the x86 systems. Sorry, I'm not familar with that stuff.

x86 might use 80 bit for some double operation, since that is what the FPU
provides.

Quote:> Here is a short c-source, that shows the difference. But I do'nt
> understand why the Alpha breaks too early.

I don't quite understand your question... What's happening is that you do
arithmetic with a denormalized number, which traps by default on Alpha, since
it isn't 100% IEEE-compliant. Is that what you wanted to know?

--
        Falk

-+- BBBS/NT v4.01 Flag-5
 + Origin: TCOB1: A slice of life on your plate (2:263/950)

--
This message posted from Shurato's Heavenly Sphere Telnet BBS
telnet://shurato.darktech.org

Admin of SHS.

--- BBBS/NT v4.01 Flag-5
 * Origin: TCOB1: A slice of life on your plate (2:263/950)

--
This message posted from Shurato's Heavenly Sphere Telnet BBS
telnet://shurato.darktech.org

Shurato:  Admin of SHS.

 
 
 

floating point problem

Post by Robert M. Riches J » Sat, 21 Jun 2003 03:42:00


(CHARSET: PC-8)
(PATH: 263/950 236/150 261/38 140/1 106/2000 123/500 3613/1275 134/10)

(CHARSET: PC-8)
(PATH: 263/950 236/150 261/38 140/1 106/2000 123/500 3613/1275 134/10) From:



>> It seems that the "float" and "double" range on EV6 are different to
>> the x86 systems. Sorry, I'm not familar with that stuff.

> x86 might use 80 bit for some double operation, since that is what the
> FPU provides.

>> Here is a short c-source, that shows the difference. But I do'nt
>> understand why the Alpha breaks too early.

> I don't quite understand your question... What's happening is that you
> do arithmetic with a denormalized number, which traps by default on
> Alpha, since it isn't 100% IEEE-compliant. Is that what you wanted to
> know?

For many of these problems, the solution is to add the
-mieee option to the compile command.  This has made a big
difference for me on several packages.

Good luck.

Robert Riches

(Yes, that is one of my email addresses.)

-+- BBBS/NT v4.01 Flag-5
 + Origin: TCOB1: A slice of life on your plate (2:263/950)

--
This message posted from Shurato's Heavenly Sphere Telnet BBS
telnet://shurato.darktech.org

Admin of SHS.

--- BBBS/NT v4.01 Flag-5
 * Origin: TCOB1: A slice of life on your plate (2:263/950)

--
This message posted from Shurato's Heavenly Sphere Telnet BBS
telnet://shurato.darktech.org

Shurato:  Admin of SHS.

 
 
 

1. g++-2.7.2p - BIG floating point problem!

I just upgraded everything C++-compiler related to the latest and
greatest stuff on sunsite (i.e. gcc 2.7.2p libc-5.2.18 libg++-2.7.1.3)
and am experiencing a problem display floating point values. Here is a
sample program:

-----------------------------------------------------------------------
// tester.cpp - Finds apparent bug in g++ compiler/libs
//              Note, although only one number is shown (i.e. 57.0)
//              this happens for any floating point number
// Evironment:
// gcc-2.7.2p, libc-5.2.18, libg++-2.7.1.3 (all from sunsite binaries)
// Machine is a Pentium-133 running kernel linuxelf-1.2.13

#include <iostream.h>

main()
{
  cout << "This works:" << endl;
  cout << (long double) 57.0 << endl;
  cout << "This doesn't (may be expecting a long double?!)" << endl;
  cout << (double) 57.0 << endl;
  cout << "This doesn't (may be expecting a long double?!)" << endl;
  cout << (float) 57.0 << endl;
-----------------------------------------------------------------------
Output, after 'g++ -o tester tester.cpp'

This works:
 57.0000
This doesn't (may be expecting a long double?!)
-1.49226e-4217
This doesn't (may be expecting a long double?!)
-1.24570e-2194

-----------------------------------------------------------------------

2. Difference between Motif 1.2 and 2.0

3. floating point problem

4. HOWTO: SCO Portfolio on 5.0.4

5. Floating point problem (Where did it go? :)

6. 3rd Controller wrong IRQ

7. g++-2.7.2p - BIG floating point problem!

8. help Compiling

9. AMD 486DXII66 floating point problem?

10. Floating Point Problems in Interact

11. floating point problem

12. Floating Point Problem

13. g++-2.7.2p - BIG floating point problem!