Re: [Patch, Fortran] Rework of floating point number reading

[Daniel Kraft <d at domob dot eu>]

Daniel Kraft wrote:
> Mikael Morin wrote:
> > Daniel Kraft wrote:
> > > Thomas Koenig wrote:
> > > > What about using the glibc strtod as a base, and adjust it to Fortran?
> > > > The glibc copyright is already with the FSF, so I wouldn't expect legal
> > > > problems, but, of course, IANAL.
> > > Actually, I don't think this is a good idea, as (at least if strtod does
> > > really do some "magic" to get around the rounding problem as much as
> > > possible) this sounds like including possibly a lot of system-dependent,
> > > complicated code into libgfortran that does not really belong there.
> > > Just my opinion, though.
> > I think it is a good idea. If we keep the code as is, with a call to
> > strtod, we parse the string twice, the first time in libgfortran, and
> > the second time in strtod. Adding 'e' for example (for exponent) to a
> > strtod base won't add any complexity to the strtod code, so the speed
> > will be the same. However, supporting it without touching strtod adds a
> > lot of unnecessary code.
> > Just my opinion too ;-)

For anyone interested, I looked at glibc-2.4 (the one on my system) 's 
implementation, which is in stdlib/strtod_l.c and around 1600 lines of 
code; I would not want to include this one in gfortran, to be honest.

The basic idea is to to the same as my patch does, but use a gmp natural 
number for the *10+digit thing.  For the division, it uses a table of 
powers of ten instead of pow and copied code from GMP because it states 
that not a full multiprecision division is needed but instead only a few 
digits.  So here's another suggestion: Do the calculation ourselves but 
use GMP for it?  I think we could do a simple code, not that optimized 
and special-case-handling as the one in glibc, but (hopefully) with the 
same precision.  It seems (?) that strtod uses GMP anyway, so can we do 
that, too, in libgfortran?  Or are there systems libgfortran is supposed 
to work on even without GMP (there we could simply use floating-point 
numbers and allow the loss of precision)?  I hesitated to do my 
calculation with large integers in the first place because I feared slow 
code; but if glibc does it, it can't be too bad, I guess.

Daniel

--
Done:  Arc-Bar-Cav-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran