computing exp(1.0) on SPARC.
in [Solaris]
|
From: Richard B. Gilbert on 1 Jan 2010 09:56 Stuart Biggar wrote: > 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 It is extremely rare to actually need that many significant figures for e, pi, and the various functions of e and pi!
From: Chris Ridd on 1 Jan 2010 12:05 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
From: David Kirkby on 1 Jan 2010 16:11 On Jan 1, 2:06 pm, Stuart Biggar <sbig...(a)email.arizona.edu> wrote: > 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 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
From: Nemo ad Nusquam on 1 Jan 2010 17:26 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
From: Richard B. Gilbert on 1 Jan 2010 18:07
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). 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. |