[Discuss] Unix date beyond 2057

[Alan W. Irwin]

On 2008-02-29 09:35-0800 John Blomfield wrote:

> Alan W. Irwin wrote:
>> [...]Normally, I pooh-pooh any such
>> conclusion about limits for computers because so many have been so wrong
>> about that before, but nevertheless, a 128-bit machine would have integer
>> ranges that are 2^{64} times larger than a current 64-bit machine, and it
>> really is hard to conceive of any practical software application that 
>> would
>> overflow such a huge integer range.
>> 
> Such a machine is probably of interest to groups involved with the 
> mathematical modeling (numerical analysis) of complex physical systems e.g. 
> weather forecasting, climate models, aerodynamic fluid flow etc. that are 
> essentially solving initial value multi-dimensional differential equations, 
> stepping forward into time.  These models suffer from rounding errors and the 
> difficulty of predicting the propagation of butterfly type events.  In these 
> cases the more precision i.e. the more bits per word the better.  Having said 
> that this is normally the realm of the big number crunching machines that are 
> probably already 128 bit (I'm a bit out of touch these days) and not the PC 
> world.

Hi John:

On 32-bit machines (as measured by the length of integers), typically you
have 32-bit, 64-bit, and sometimes even 128-bit floating point exactly
because of the floating-point rounding problems you mention.  For example,
my FreeEOS code is written in 64-bit floating point (all Fortran
floating-point variables are typed as real(kind=8)) because in the worst
case roughly 6 decimal digits of precision are lost due to rounding errors.
real(kind=8) ideally has 17 decimal digits of precision so that leaves at
least 11 "good" digits in my FreeEOS results, and I am extremely happy with
that level of numerical precision for those results.

However, I have also run into problems (notably certain least-squares fits
with a large degree of correlation between the fitted parameters) where
64-bit floating point was not enough. Because I did not have access to
128-bit floating point I had to abandon the fit I was trying to do.  I
suspect if I had had access to 128-bit floating point, I would have found a
solution with extremely large formal errors (i.e., the solution would not be
useful) due to the large degree of correlation, but it would have been nice
to show that explicitly rather than just guess from the numerical problems
at the 64-bit level that the fit would probably not yield useful results at
the 128-bit level of precision.

BTW, I just checked on my new 64-bit machine, and gfortran does not support
real(kind=16) (i.e., 128-bit floating point).  I assume the same limitation
is in the gcc C compiler since gfortran (the gcc Fortran compiler) uses a
lot of the compilation machinery of the gcc C compiler. That current
limitation of gcc on 64-bit machines is disappointing, but I assume they
will get it straightened out since all the compiler logic is there to have
floating-point word length twice the integer word length on 32-bit machines
so doing that for 64-bit machines should be trivial.

Sorry I have gone so far off the original topic, but all this stuff is
personally interesting to me, and I hope it is interesting to others here
as well.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________