computing exp(1.0) on SPARC.
in [Solaris]
|
From: Uros Nedic on 1 Jan 2010 18:12 "Stuart Biggar" <sbiggar(a)email.arizona.edu> wrote in message news:gf1%m.1$_H7.0(a)newsfe24.iad... > On 12/30/09 5:52 PM, David Kirkby wrote: >> 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(a)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(a)kestrel:~$ uname -a >> SunOS kestrel 5.10 Generic_141444-09 sun4u sparc SUNW,UltraAX-i2 >> drkirkby(a)kestrel:~$ gcc exp.c >> drkirkby(a)kestrel:~$ ./a.out >> 2.7182818284590451 >> drkirkby(a)kestrel:~$ /opt/sunstudio12.1/bin/cc -lm exp.c >> drkirkby(a)kestrel:~$ ./a.out >> 2.7182818284590455 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
From: David Kirkby on 1 Jan 2010 19:51 On Jan 1, 11:12 pm, "Uros Nedic" <ur...(a)beotel.rs> wrote: > "Stuart Biggar" <sbig...(a)email.arizona.edu> wrote in message > > news:gf1%m.1$_H7.0(a)newsfe24.iad... > > > > > On 12/30/09 5:52 PM, David Kirkby wrote: > >> 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(a)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(a)kestrel:~$ uname -a > >> SunOS kestrel 5.10 Generic_141444-09 sun4u sparc SUNW,UltraAX-i2 > >> drkirkby(a)kestrel:~$ gcc exp.c > >> drkirkby(a)kestrel:~$ ./a.out > >> 2.7182818284590451 > >> drkirkby(a)kestrel:~$ /opt/sunstudio12.1/bin/cc -lm exp.c > >> drkirkby(a)kestrel:~$ ./a.out > >> 2.7182818284590455 > > 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 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(a)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(a)swan:[~] $ /opt/sunstudio12.1/bin/cc -lm exp2.c drkirkby(a)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(a)swan:[~] $ ./a.out 2.7182818284590455
From: Uros Nedic on 2 Jan 2010 02:51 On OpenSolaris for SPARC it works fine. I have even older version of SunStudio and here is the output: urosn(a)urosn:~$ uname -a SunOS urosn 5.11 snv_105 sun4v sparc SUNW,SPARC-Enterprise-T5120 Solaris urosn(a)urosn:~$ cat exp.c #include <math.h> #include <stdio.h> int main() { printf("%.16lf\n",exp(1.0)); } urosn(a)urosn:~$ cc -lm exp.c urosn(a)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(a)urosn:~$ ./a.out 2.7182818284590451 urosn(a)urosn:~$ It was error in SunStudio for Sparc at Solaris 10. In OpenSolaris it has been fixed. Regards, Uros Nedic "David Kirkby" <drkirkby(a)gmail.com> wrote in message news:0dc7652f-a92c-47c7-92a7-e292102d7d08(a)e27g2000yqd.googlegroups.com... On Jan 1, 11:12 pm, "Uros Nedic" <ur...(a)beotel.rs> wrote: > "Stuart Biggar" <sbig...(a)email.arizona.edu> wrote in message > > news:gf1%m.1$_H7.0(a)newsfe24.iad... <snip> 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(a)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(a)swan:[~] $ /opt/sunstudio12.1/bin/cc -lm exp2.c drkirkby(a)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(a)swan:[~] $ ./a.out 2.7182818284590455
From: Paul Floyd on 2 Jan 2010 17:58 On Fri, 01 Jan 2010 18:07:43 -0500, Richard B. Gilbert <rgilbert88(a)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
From: David Kirkby on 3 Jan 2010 00:51
On 31 Dec 2009, 17:40, Chris Ridd <chrisr...(a)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 |