[Patch, Fortran] Rework of floating point number reading
Daniel Kraft
d@domob.eu
Tue Dec 30 17:18:00 GMT 2008
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
More information about the Gcc-patches
mailing list