Has R been ported to 64-bit platforms? E.g. as in FORTRAN when you define double precision number as: REAL*16 I have heard that some SUN computers already offer 64-bit architecture but I am unsure about the GNU support for that hardware. I am seeking increased accuracy in floating point operations. regards Helgi -- Helgi Tomasson FAX: 354-552-6806 University of Iceland PHONE:354-525-4571 Faculty of Economics and Business Administration email:helgito at rhi.hi.is Oddi v/ Sturlugotu IS-101 Reykjavik ICELAND -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Tue, 11 Sep 2001 helgito at hi.is wrote:> Has R been ported to 64-bit platforms? E.g. as in FORTRAN when you > define > double precision number as: > > REAL*16 > > I have heard that some SUN computers already offer 64-bit architecture > but I am unsure > about the GNU support for that hardware. I am seeking increased > accuracy in floating > point operations.We run R in 64-bit mode on Suns under the native compiler. However, the double type in 64-bit mode is 8 bytes, not 16 bytes, and that's part of the agreement between manufacturers for 64-but platforms as we understand it: int - 4 bytes long - 8 bytes double - 8 bytes The 64-bit refers to the pointer size and perhaps to buses and to the preferred size for integer arithmetic. It does not refer to the FPU, and FPUs have been 64 bits or greater (e.g. i686) for about 15 years. Why do you think REAL*16 will give you increased accuracy? Accuracy has a lot more to do with the algorithms used and their convergence criteria. As R is a statistical package, numerical accuracy is almost always secondary to data uncertainty. At least the build of gcc 3.0.1 we have does not run in -m64 mode. The potential benefit of 64-but mode is to address large amounts of virtual memory from a single process, but R has internal limits there still, I believe. -- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> > > Why do you think REAL*16 will give you increased accuracy? Accuracy has a > lot more to do with the algorithms used and their convergence criteria. > As R is a statistical package, numerical accuracy is almost always > secondary to data uncertainty. > >I tested a Solaris fotran compiler on a Sun and it allowed REAL*16 whereas a GNU fortran on the same machine did not. It seems to me that that the increased numerical accuracy compared to REAL*8 on an Intel-86 machine was not proportional. The Intel machines have a numerical stack of lenght 80 so if the Fortran program is well optimized you should not loose as as many digits as you might expect. REAL*8 gives about 15 digits in floating-point. It was my hope that REAL*16 would give around 30. In my simple experiment it seemed that I only got about 20-25. Maybe the Sun or the compiler does not use a stack as the Intel-86 machines. I want to add several hundred thousand numbers, and their squares, which some are range from maybe 10^(-6) to 1 or more. With crude programming I fear that I am loosing important digits. I was wondering whether I should apply for a Sun station or wait further development. regards Helgi> > ---- Helgi Tomasson FAX: 354-552-6806 University of Iceland PHONE:354-525-4571 Faculty of Economics and Business Administration email:helgito at rhi.hi.is Oddi v/ Sturlugotu IS-101 Reykjavik ICELAND -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Tue, 11 Sep 2001 helgito at hi.is wrote:> > > > > > Why do you think REAL*16 will give you increased accuracy? Accuracy has a > > lot more to do with the algorithms used and their convergence criteria. > > As R is a statistical package, numerical accuracy is almost always > > secondary to data uncertainty. > > > > > > I tested a Solaris fotran compiler on a Sun and it allowed REAL*16 whereas > a GNU fortran on the same machine did not. It seems to me that that the > increased > numerical accuracy compared to REAL*8 on an Intel-86 machine was not > proportional. The Intel machines have a numerical stack of lenght 80 so if > the Fortran program is well optimized you should not loose as as many digits > as you might expect. > REAL*8 gives about 15 digits in floating-point. It was my hope that REAL*16 > would give around 30. In my simple experiment it seemed that I only got > about 20-25. > Maybe the Sun or the compiler does not use a stack as the Intel-86 machines. > > I want to add several hundred thousand numbers, and their squares, which some > are range from maybe 10^(-6) to 1 or more. > With crude programming I fear that I am loosing important digits.> I was wondering whether I should apply for a Sun station or wait further > development.Better to learn some numerical analysis. For example you could sum the smallest first. If you want centred moments, centre first .... There is a whole science out there of getting accurate results with low precision (it was needed where the only fast arithmetic was a few hexadecimal digits). That could be tricky and even needed iterative refinement, but double precision swept all that away at least of statistical purposes (except perhaps for people who think the normal equations are the way to solve least-squares problems). -- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._