computing exp(1.0) on SPARC.

David Kirkby

unread,

Dec 30, 2009, 7:52:42 PM12/30/09

to

The value of E^1 is
2.71828182845904523536028747135266249775724709369995957496696...

Trying this noddy C program, I get a different answer from gcc than I
do from Sun Studio on SPARC. GCC gets it more accurate than Sun
Studio. On Open Solaris, using a Xeon processor, the two compilers
give the same result. I get the same result on HP-UX with both GCC and
HP's native compiler.

But for reasons unknown, Sun Studio gives a different answer on
SPARC.

drkirkby@kestrel:~$ cat exp.c
#include <math.h>
#include <stdio.h>

int main() {
printf("%.16lf\n",exp(1.0));
}

This data below is from a Sun Netra T1 SPARC (sun4u architecture) of
mine. I've tried on another SPARC, in that case a T5240 (sun4v) and
get exactly the same results.

drkirkby@kestrel:~$ uname -a
SunOS kestrel 5.10 Generic_141444-09 sun4u sparc SUNW,UltraAX-i2
drkirkby@kestrel:~$ gcc exp.c
drkirkby@kestrel:~$ ./a.out
2.7182818284590451
drkirkby@kestrel:~$ /opt/sunstudio12.1/bin/cc -lm exp.c
drkirkby@kestrel:~$ ./a.out
2.7182818284590455

Now, when I do this on Open Solaris, I get the same result with each
compiler.

bash-3.2$ uname -a
SunOS hawk 5.11 snv_111b i86pc i386 i86pc
bash-3.2$ gcc exp.c
bash-3.2$ ./a.out
2.7182818284590451
bash-3.2$ /opt/sunstudio12.1/bin/cc -lm exp.c
bash-3.2$ ./a.out
2.7182818284590451

I also tried this on HP-UX, and get the same (correct) result with
both the
native HP compiler and with gcc.

-bash-4.0$ uname -a
HP-UX hpbox B.11.11 U 9000/785 2016698240 unlimited-user license
-bash-4.0$ gcc exp.c
-bash-4.0$ ./a.out
2.7182818284590451
-bash-4.0$ cc -lm exp.c
-bash-4.0$ ./a.out
2.7182818284590451

Michael Laajanen

unread,

Dec 31, 2009, 4:02:43 AM12/31/09

to

Hi,

I get the same results, also tried sunstudioexpress_2009.03

/michael

Chris Ridd

unread,

Dec 31, 2009, 4:16:27 AM12/31/09

to

I don't play with floating point much, but are there any
compiler/linker options that will change things?

--
Chris

Stuart Biggar

unread,

Dec 31, 2009, 7:59:56 AM12/31/09

to

David,

I'm no expert in floating point but do use it. I wouldn't
expect different compilers on different architectures to get
consistent results in double precision to better than what
is defined in float.h (from a SPARC running Solaris 10U4):

DBL_DIG is defined as 15 and
DBL_EPSILON is defined as a bit over 2.2e-16

So I wouldn't expect computations in double precision to
have more than 15 significant digits. Some (few) values may
be exact but most will not be.

If you need better precision, try 80-bit on x86 or quad
precision on SPARC (LDBL). That should result in 18 or 33
significant digits. In any case, floating point is only
a (probably inaccurate to some degree) representation of
the real number you are trying to calculate. There are
all sorts of traps for the unwary in floating point. I've
found that you have to be very careful how you compute
things - mathematically equal ways of representing a
quantity can compute quite differently with precision
VERY much worse than you might expect. Extended precision
can help some but isn't the real fix (and it may slow
things down considerably).

Stuart

David Kirkby

unread,

Dec 31, 2009, 10:33:40 AM12/31/09

to

On Dec 31, 12:59 pm, Stuart Biggar <sbig...@email.arizona.edu> wrote:
> David,
>
> I'm no expert in floating point but do use it. I wouldn't
> expect different compilers on different architectures to get
> consistent results in double precision to better than what
> is defined in float.h (from a SPARC running Solaris 10U4):
>
> DBL_DIG is defined as 15 and
> DBL_EPSILON is defined as a bit over 2.2e-16
>
> So I wouldn't expect computations in double precision to
> have more than 15 significant digits. Some (few) values may
> be exact but most will not be.
>
> If you need better precision, try 80-bit on x86 or quad
> precision on SPARC (LDBL). That should result in 18 or 33
> significant digits. In any case, floating point is only
> a (probably inaccurate to some degree) representation of
> the real number you are trying to calculate. There are
> all sorts of traps for the unwary in floating point. I've
> found that you have to be very careful how you compute
> things - mathematically equal ways of representing a
> quantity can compute quite differently with precision
> VERY much worse than you might expect. Extended precision
> can help some but isn't the real fix (and it may slow
> things down considerably).
>
> Stuart

Thank you Stuart.

But the issue here is not simply different compilers on different
architectures, but different compilers on the *same* architecture.

Sun Studio on SPARC is unique among all the different compilers tried
(gcc, HP, Sun Studio) on different platforms (x86, SPARC, PA-RISC and
some unknown to me processor on which AIX 6.1 is running). I can only
check with gcc on AIX - there is no valid IBM compiler.

1) The correct answer is
2.71828182845904523536028747135266249775724709369995957496696... goes
on forever.

2) Rounded to within the limits specific by DBL_EPSILON in float.h
(2.2204460492503130808473 x 10^-16), E should be 2.7182818284590451 (a
better answer, using no more decimal digits would be
2.7182818284590452)

3) Sun Studio on SPARC gives: 2.7182818284590455, which is not a
correctly rounded representation of E.

4) Every other compiler / OS gives the the correctly rounded number.

* GCC on SPARC gives 2.7182818284590451
* Sun Studio on Solaris x86 gives 2.7182818284590451
* GCC on Solaris x86 gives 2.7182818284590451
* GCC on Linux x86 gives 2.7182818284590451
* HP's compiler on HP-UX gives 2.7182818284590451
* GCC on HP-UX gives 2.7182818284590451
* GCC on AIX gives 2.7182818284590451

That does strike me as a bit strange, given E is a fundamental
constant. But perhaps I should not be too surprised.

I do not need higher precision for this. The problem was discovered
when the self-tests were run on the Sage open-source maths software.

http://www.sagemath.org/

of which I am one of the developers. (My main interest has been
porting Sage to Solaris.) A test for the value of E using machine
precision was failing, which led to some further investigations.

There are libraries in Sage which implement arbitrary precision
computations of floating point numbers, but that's not the issue
here.

Dave

John D Groenveld

unread,

Dec 31, 2009, 12:27:42 PM12/31/09

to

In article <a9121688-3815-4fef...@l30g2000yqb.googlegroups.com>,

David Kirkby <drki...@gmail.com> wrote:
>Sun Studio on SPARC is unique among all the different compilers tried
>(gcc, HP, Sun Studio) on different platforms (x86, SPARC, PA-RISC and

The Sun Studio developers have some web forums:
<URL:http://developers.sun.com/sunstudio/community/index.jsp>

John
groe...@acm.org

Chris Ridd

unread,

Dec 31, 2009, 12:40:52 PM12/31/09

to

On 2009-12-31 15:33:40 +0000, David Kirkby said:

> Thank you Stuart.
>
> But the issue here is not simply different compilers on different
> architectures, but different compilers on the *same* architecture.
>
> Sun Studio on SPARC is unique among all the different compilers tried
> (gcc, HP, Sun Studio) on different platforms (x86, SPARC, PA-RISC and
> some unknown to me processor on which AIX 6.1 is running). I can only
> check with gcc on AIX - there is no valid IBM compiler.
>
> 1) The correct answer is
> 2.71828182845904523536028747135266249775724709369995957496696... goes
> on forever.
>
> 2) Rounded to within the limits specific by DBL_EPSILON in float.h
> (2.2204460492503130808473 x 10^-16), E should be 2.7182818284590451 (a
> better answer, using no more decimal digits would be
> 2.7182818284590452)
>
> 3) Sun Studio on SPARC gives: 2.7182818284590455, which is not a
> correctly rounded representation of E.

cc -xlibmopt (Studio 12) on SPARC gives 2.7182818284590451 BTW.

The C User's Guide has a number of options that affect floating point,
but -xlibmopt was the only one I found that changed the result to end
in 51.

--
Chris

Raymond Toy

unread,

Dec 31, 2009, 1:02:31 PM12/31/09

to

Why are these correctly rounded when the true result is
2.718...459045235? Why should they not end in 452, not 451?

Perhaps gcc on sparc uses libm but sunstudio provides its own, different
libm?

The source code for Sun's libm is available and can be found in glibc.
That version might be old though, but it could tell you why the answer
is slightly different. And the printed output depends on libc so that
can also affect the output. Glibc used to have some issues what that
but perhaps that has been fixed too.

Ray

David Kirkby

unread,

Dec 31, 2009, 8:42:16 PM12/31/09

to

On Dec 31 2009, 6:02 pm, Raymond Toy <toy.raym...@gmail.com> wrote:
> David Kirkby wrote:

> > * GCC on SPARC gives 2.7182818284590451
> > * Sun Studio on Solaris x86 gives 2.7182818284590451
> > * GCC on Solaris x86 gives 2.7182818284590451
> > * GCC on Linux x86 gives 2.7182818284590451
> > * HP's compiler on HP-UX gives 2.7182818284590451
> > * GCC on HP-UX gives 2.7182818284590451
> > * GCC on AIX gives 2.7182818284590451
>
> Why are these correctly rounded when the true result is
> 2.718...459045235? Why should they not end in 452, not 451?

Hi Ray,

It's impossible to 2.7182818284590452 in the IEEE format. All double
precision real numbers in IEEE 754 format are of the form:

(S)^-1 * C * 2^q
S=Sign bit
C=Significand
q=Exponent

The following two numbers
6121026514868073 * 2^(-51) =
2.71828182845904509079559829842764884233474731445312...
and
6121026514868074 * 2^(-51) =
2.71828182845904523536028747135266249775724709369995957 ...

can be represented, but nothing in between them. The closest of them
to E is 2.71828182845904509079559829842764884233474731445312.

> Perhaps gcc on sparc uses libm but sunstudio provides its own, different
> libm?

It would appear from some work done by someone else, that the Sun
maths library computes this to be 2.7182818284590455.... In the
trivial program I wrote, gcc inlines E which gives a more accurate
result. But in a more complex program, gcc will call the Sun maths
library, which will return 2.7182818284590455. The program does not
have to be very complex. This example, written by Gonzalo Tornaria
(see the sage-devel mailing list for more), shows how gcc will also
give 2.7182818284590455 on SPARC.

#include <math.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
double x = 1.0;
if (argc>1)
x = atof(argv[1]);
printf("%.16lf\n",exp(x));
}

From what I gather, this does not necessarily mean the maths library
is broken. The libraries do not guarantee to return the most accurate
result, so there will be some degree of tradeoff with accuracy and
speed.

I'm guessing that since the SPARC processor uses 64-bit for the
computations, but the Intel processors uses 80 bits internally, there
is justification for choosing a slightly less accurate but faster
implementation on SPARC.

I'm no expert on this, but have a better understanding of it then I
did a day or two ago.

Dave

Stuart Biggar

unread,

Jan 1, 2010, 9:06:57 AM1/1/10

to

On 12/31/09 6:42 PM, David Kirkby wrote:

> I'm guessing that since the SPARC processor uses 64-bit for the
> computations, but the Intel processors uses 80 bits internally, there
> is justification for choosing a slightly less accurate but faster
> implementation on SPARC.
>
> I'm no expert on this, but have a better understanding of it then I
> did a day or two ago.
>
> Dave

Dave,

On various Intel platforms, double precision may use SSE where
the math is done at 64-bit, not the extended precision of 80-bit
used in the 80N87 (math co-processor). Also at least one Windows
C compiler silently converts long doubles to doubles to allow use
of the faster SSE stuff - gives "interesting" results when the
code specifically tries to use 80-bits for accuracy.

If you need an accurate value for e, it is defined in one of
the include files along with various other constants like
pi and fractions of pi (from math.h on SPARC S10U4):

#define M_E 2.7182818284590452354
#define M_LOG2E 1.4426950408889634074
#define M_LOG10E 0.43429448190325182765
#define M_LN2 0.69314718055994530942
#define M_LN10 2.30258509299404568402
#define M_PI 3.14159265358979323846
#define M_PI_2 1.57079632679489661923
#define M_PI_4 0.78539816339744830962
#define M_1_PI 0.31830988618379067154
#define M_2_PI 0.63661977236758134308
#define M_2_SQRTPI 1.12837916709551257390
#define M_SQRT2 1.41421356237309504880
#define M_SQRT1_2 0.70710678118654752440

With Studio you can also use optimized math libraries.
I have no idea if the values of things would change
by linking with them (typically done automatically if
you optimize using -fast and maybe other options or
manually during the link step).

Stuart

Richard B. Gilbert

unread,

Jan 1, 2010, 9:56:24 AM1/1/10

to

It is extremely rare to actually need that many significant figures for
e, pi, and the various functions of e and pi!

Chris Ridd

unread,

Jan 1, 2010, 12:05:56 PM1/1/10

to

On 2010-01-01 14:56:24 +0000, Richard B. Gilbert said:

> It is extremely rare to actually need that many significant figures for
> e, pi, and the various functions of e and pi!

Unless you're developing a mathematics package, perhaps?
--
Chris

David Kirkby

unread,

Jan 1, 2010, 4:11:41 PM1/1/10

to

Thank you Stuart.

That's useful to know. I was not aware of that.

IIRC, there are ways at getting at the extra bits in the 80387 and I
assume later versions of the chip too. I can't recall the details, but
remember writing some assembler in the dim and distant past and
playing with the internal values.

Sun Studio is not currently an option - there are too many GNUisms to
let Sage build with that. Getting rid of sufficient of them to make it
build on SPARC with gcc was a major headache.

BTW,

If anyone wants to take a look at Sage, here's a simple example of a
Torus being plotted, and 100 factorial computed. You can rotate the
torus. If you create yourself an account, you can modify the code.

http://t2nb.math.washington.edu:8000/home/pub/0/

You can create yourself an account (no need for an email address)

http://t2nb.math.washington.edu:8000/

That's running on a Sun T5240, but Sage is not debugged on Solaris.
Some things are not implemented,

A most stable server is at

http://www.sagemath.org/

which is running on Linux.

Building Sage on Solaris is not exactly trivial, but it will build.
However, it only currently builds as a 32-bit application on Solaris
10, and even then, some things do not work right.

Sage does not currently run on Open Solaris, but will run on Solaris
10 (SPARC). You can download the source

http://www.sagemath.org/

and try it. More info on building on Solaris 10 (SPARC) can be found
at

http://wiki.sagemath.org/solaris

Don't be too shocked the source is a tar file, rather than a .tar.gz.
The source consists of a lot of packages which are themselves
compressed with bzip2.

It takes just over a day to compile on a Sun Blade 2000 with 2 x 1200
MHz. So it's not a 5-minute job to build it! On Niagra it is taking
much longer, due to the fact some tuning data does not exist for the
Niagra processors. That needs fixing.

Dave

Nemo ad Nusquam

unread,

Jan 1, 2010, 5:26:33 PM1/1/10

to

Dave:

David Kirkby wrote (in part):

> Building Sage on Solaris is not exactly trivial, but it will build.
> However, it only currently builds as a 32-bit application on Solaris
> 10, and even then, some things do not work right.

Good work! It would be very nice to have Sage running on more than
Intel boxes. Thank you.

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

Richard B. Gilbert

unread,

Jan 1, 2010, 6:07:43 PM1/1/10

to

I suspect that even a mathematics package does not need 20 significant
figures (or whatever the actual number was).

Even if you know pi or e to 200 significant figures, three to five
significant figures are sufficient for most *practical* calculations.
For example, if you are calculating how much paint is required to cover
a circle with a radius of ten feet you could use pi=3.14 to calculate
the area. You don't calculate it down to the last milliliter because
you can't *buy* paint by the milliliter; it comes in half pints, pints,
quarts, gallons or *maybe* five gallon cans! At the paint store you
would ask for "enough to cover about 300 square feet with two coats".

A mathematician wouldn't even bother with the numerical value, he would
just write the Greek character for "pi" and move on.

Uros Nedic

unread,

Jan 1, 2010, 6:12:00 PM1/1/10

to

"Stuart Biggar" <sbi...@email.arizona.edu> wrote in message
news:gf1%m.1$_H...@newsfe24.iad...

Please, try to use newest SunStudio compiler 2009.03. This error
has been fixed. If you have problems just reply.

Thank you for porting Sage on (Open)Solaris.

Uros Nedic, Executive Leader
OpenSolaris Serbia

David Kirkby

unread,

Jan 1, 2010, 7:51:06 PM1/1/10

to

On Jan 1, 11:12 pm, "Uros Nedic" <ur...@beotel.rs> wrote:
> "Stuart Biggar" <sbig...@email.arizona.edu> wrote in message

I've got Sun Studio 12.1. Note this problem is only on SPARC, not on
x86. I've not tried Open Solaris on SPARC,

drkirkby@swan:[~] $ cat exp2.c

#include <math.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {

FILE *fp;
double x = 1.0, y;

if (argc>1)
x = atof(argv[1]);

y=exp(x);
printf("%.16lf\n",y);
fp=fopen("exp2.dat","w");
fwrite(&y,8,1,fp);
fclose(fp);
}

drkirkby@swan:[~] $ /opt/sunstudio12.1/bin/cc -lm exp2.c
drkirkby@swan:[~] $ /opt/sunstudio12.1/bin/cc -V
cc: Sun C 5.10 SunOS_sparc 2009/06/03
usage: cc [ options] files. Use 'cc -flags' for details
drkirkby@swan:[~] $ ./a.out
2.7182818284590455

Uros Nedic

unread,

Jan 2, 2010, 2:51:13 AM1/2/10

to

On OpenSolaris for SPARC it works fine. I have even older version of
SunStudio
and here is the output:

urosn@urosn:~$ uname -a
SunOS urosn 5.11 snv_105 sun4v sparc SUNW,SPARC-Enterprise-T5120 Solaris
urosn@urosn:~$ cat exp.c

#include <math.h>
#include <stdio.h>
int main()
{
printf("%.16lf\n",exp(1.0));
}

urosn@urosn:~$ cc -lm exp.c
urosn@urosn:~$ cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-11 2009/04/30

usage: cc [ options] files. Use 'cc -flags' for details

urosn@urosn:~$ ./a.out
2.7182818284590451
urosn@urosn:~$

It was error in SunStudio for Sparc at Solaris 10. In OpenSolaris it has
been fixed.

Regards,
Uros Nedic

"David Kirkby" <drki...@gmail.com> wrote in message
news:0dc7652f-a92c-47c7...@e27g2000yqd.googlegroups.com...

On Jan 1, 11:12 pm, "Uros Nedic" <ur...@beotel.rs> wrote:
> "Stuart Biggar" <sbig...@email.arizona.edu> wrote in message
>
> news:gf1%m.1$_H...@newsfe24.iad...

<snip>

Paul Floyd

unread,

Jan 2, 2010, 5:58:49 PM1/2/10

to

On Fri, 01 Jan 2010 18:07:43 -0500, Richard B. Gilbert
<rgilb...@comcast.net> wrote:
> Chris Ridd wrote:
>> On 2010-01-01 14:56:24 +0000, Richard B. Gilbert said:
>>
>>> It is extremely rare to actually need that many significant figures for
>>> e, pi, and the various functions of e and pi!
>>
>> Unless you're developing a mathematics package, perhaps?
>
> I suspect that even a mathematics package does not need 20 significant
> figures (or whatever the actual number was).

Sure, if you don't want the right answers, then not having the option to
have the precision necessary to obtain the solution is fine.

> significant figures are sufficient for most *practical* calculations.
> For example, if you are calculating how much paint is required to cover
> a circle with a radius of ten feet you could use pi=3.14 to calculate
> the area. You don't calculate it down to the last milliliter because
> you can't *buy* paint by the milliliter; it comes in half pints, pints,
> quarts, gallons or *maybe* five gallon cans! At the paint store you
> would ask for "enough to cover about 300 square feet with two coats".

The mind boggles. It has never occurred to me to use such mathematical
software to calculate the area of a circle for the purpose of
painting it.

> A mathematician wouldn't even bother with the numerical value, he would
> just write the Greek character for "pi" and move on.

Have you ever heard of calculus? If you have, then I hope that you are
aware that not all differential equations have a formal solution.
In order to solve them, numerical methods are required. Usually machine
precision is adequate (and fast), but sometimes more precision is
needed.

Paul
--
Paul Floyd http://paulf.free.fr

David Kirkby

unread,

Jan 3, 2010, 12:51:53 AM1/3/10

to

On 31 Dec 2009, 17:40, Chris Ridd <chrisr...@mac.com> wrote:

> The C User's Guide has a number of options that affect floating point,
> but -xlibmopt was the only one I found that changed the result to end
> in 51.
>
> --
> Chris

Thanks Chris, that is very useful. I'll have to have a read up on
that. At the minute, Sage will not build with Sun Studio, so it's not
an option, though perhaps,using the CoolTools, it might be possible to
do likewise.

I tried the computation on Mathematica 7 on a SPARC and get the same
results as the noddy C program.

Dave

David Kirkby

unread,

Jan 3, 2010, 1:17:21 AM1/3/10

to

On 1 Jan, 22:26, Nemo ad Nusquam <inva...@invalid.invalid> wrote:
> Dave:
>
> David Kirkby wrote (in part):
>
> > Building Sage on Solaris is not exactly trivial, but it will build.
> > However, it only currently builds as a 32-bit application on Solaris
> > 10, and even then, some things do not work right.
>
> Good work! It would be very nice to have Sage running on more than
> Intel boxes. Thank you.

It's only recently got it there. The is a lot of code in Sage - the
compressed source code is around 260 MB. The university of Washington
was donated a T5240 by Sun, but the architecture of that machine has
not really been ideal for developing on. I luckily had my own Blade
2000, but Sage took a day or more to build on that.

These was until recently a very annoying bug, which meant that Sage
would build if Sun Studio was not installed, but would not build if
Sun Studio was installed. Finally, after many months, the cause of it
has been identified. Of couse, we could have hacked the code to get it
to work, or as root you could move Sun Studion to a non-standard
place, but these were all hacks.

unread,

Jan 3, 2010, 11:14:58 AM1/3/10

to

On Jan 3, 9:14 am, Michael Laajanen <michael_laaja...@yahoo.com>
wrote:

I have an SGI Octane running IRIX, a Dec Alpha running Tru64 and an
IBM RS/6000 running AIX. In principle, Sage could be ported to any of
them, but I think AIX and HP-UX are the only worthwhile ones now.

If you want to try a port to IRIX, you are welcome to. I've started
writing the code in a way it will work with IRIX. There are specific
tests for IRIX, specific tests for the SGI IRIX compilers. I'm
planning for the future, but I suspect IRIX port will never happen.
But where I can add code that would make a port less hassle, without
too much effort on my part, then it gets added.

If you use IRIX, and want to port it, let me know.

Dave

David Kirkby

unread,

Jan 3, 2010, 11:19:04 AM1/3/10

to

Are you sure about this? I downloaded 60-day trial versions only a
month or so back.

-bash-4.0$ /opt/aCC/bin/aCC -V
aCC: HP ANSI C++ B3910B A.03.85

That is not free, neither is the C compiler.

Dave

Chris Ridd

unread,

Jan 3, 2010, 12:02:12 PM1/3/10

to

You're right. It seems you've got to be a "DSPP partner", but I think
that is a free for individuals as well as companies.

unread,

Jan 4, 2010, 7:03:37 PM1/4/10

to

It is, of course, possible to do floating point operations using
software emulation but most systems I've worked with did FP in hardware.
Typically you could have 32 bit or 64 bit FP with 24 or 56 bits of
precision. Any arbitrary precision is available in a software emulation
but it would be dog slow on most hardware.

David Kirkby

unread,

Jan 4, 2010, 11:23:56 PM1/4/10

to

On Jan 4, 11:46 pm, Tim Bradshaw <t...@tfeb.org> wrote:

True, but if you develop mathematical software, you need to check it.
When you find something behaving differently on one platform to
another, one needs to investigate that.

On 64-bit machines, multi-precision arithmetic is about 4x as fast as
on 32-bits. A lot of the libraries for this uses assembly code to get
the best possible speed.

One of the problems is that in general it is impossible to know what
precision you need to use for intermediate calculations, even if you
know what precision you need for the result. It is often a lot higher
than what's needed for the final result.

Glenn

unread,

Jan 5, 2010, 1:47:25 PM1/5/10

to

If floating-point is important to your applications, you need to read
this paper ("What Every Computer Scientist Should Know About Floating-
Point Arithmetic"), reprinted from an old Computing Surveys tutorial:

http://dlc.sun.com/pdf/800-7895/800-7895.pdf
ftp://ftp.quitt.net/Outgoing/goldbergFollowup.pdf

The second copy has some additional material at the end.

Tim Bradshaw

unread,

Jan 5, 2010, 3:34:25 PM1/5/10

to

On 2010-01-05 04:23:56 +0000, David Kirkby <drki...@gmail.com> said:

> True, but if you develop mathematical software, you need to check it.
> When you find something behaving differently on one platform to
> another, one needs to investigate that.

Yes, sorry, I wasn't particularly thinking you were wrong to worry!

Tim Bradshaw

unread,

Jan 5, 2010, 4:24:39 PM1/5/10

to

On 2010-01-05 00:03:37 +0000, "Richard B. Gilbert"
<rgilb...@comcast.net> said:

> It is, of course, possible to do floating point operations using
> software emulation but most systems I've worked with did FP in hardware.
> Typically you could have 32 bit or 64 bit FP with 24 or 56 bits of
> precision. Any arbitrary precision is available in a software
> emulation but it would be dog slow on most hardware.

I'm pretty sure REDUCE has floating-point (really "inexact" would be a
better term) with user-defined precision. Mathematica certainly does:

N[E, 50] 2.7182818284590452353602874713526624977572470937000

CLISP, I think, has user-defined precision inexact floats in the language.

As you say, these things will be very slow compared with machine floats
on almost any hardware one can imagine. I'm guessing they have their
uses other than the obvious "show me 1000 digits of pi" type thing, or
people would not implement them. I'm guessing that, apart from
anything else they let you experiment with the sensitivity of numerical
algorithms to precision.

Uros Nedic

unread,

Jan 6, 2010, 2:23:21 PM1/6/10

to

I do not know which version of Solaris 10 you are using but there are all
updates SUN did so far for Solaris 10. Install all patches and try again to
compile.

Let me know what happened.

Uros

"David Kirkby" <drki...@gmail.com> wrote in message

news:c6cd81e8-c001-4be3...@r5g2000yqb.googlegroups.com...