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

[Daniel Kraft <d at domob dot eu>]

Mikael Morin wrote:
> Daniel Kraft wrote:
> > Thomas Koenig wrote:
> > > On Tue, 2008-12-30 at 09:37 +0100, Daniel Kraft wrote:
> > >
> > > > 3.) Keep using strtod; I'm quite sure we can speed up the existing
> > > > code still significantly by optimizing how the string passed to
> > > > strtod is constructed.
> > > 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 ;-)

That's true, but without having looked at glibc's strtod code, I fear it 
won't really be something clear and easy-to-read.  If we want a simple, 
clean and fast parsing routine, we could take my patch, including the 
possible rounding errors.  If we don't want to have them, I guess the 
way strtod does it must be something ugly and system-dependent (at least 
if strtod really does a lot better than my naive implementation).

So I would not want to do our own parser (or copy the one from glibc for 
the matter) if we still wanted to care about precision more than my 
patch does.  But of course it may be worth a look at the actual glibc 
code; I'll try to do this now.

Yours,
Daniel