Reading floating point

[David Feuer]

I fully expect this to be somewhat tricky, yes. But some aspects of the
current implementation strike me as pretty clearly non-optimal. What I
meant about going through Rational is that given "625e-5", say, it
calculates 625%100000, producing a fraction in lowest terms, before calling
fromRational, which itself invokes fromRat'', a division function optimized
for a special case that doesn't seem too relevant in this context. I could
be mistaken, but I imagine even reducing to lowest terms is useless here.
The separate treatment of the digits preceding and following the decimal
point doesn't do anything obviously useful either. If we (effectively)
normalize in decimal to an integral mantissa, for example, then we can
convert the whole mantissa to an Integer at once; this will balance the
merge tree better than converting the two pieces separately and combining.

On Oct 10, 2016 6:00 AM, "Yitzchak Gale" <gale at sefer.org> wrote:

The way I understood it, it's because the type of "floating point" literals
is

Fractional a => a

so the literal parser has no choice but to go via Rational. Once you
have that, you use the same parser for those Read instances to ensure
that the result is identical to what you would get if you parse it as
a literal in every case.

You could replace the Read parsers for Float and Double with much more
efficient ones. But you would need to provide some other guarantee of
consistency with literals. That would be more difficult to achieve
than one might think - floating point is deceivingly tricky. There are
already several good parsers in the libraries, but I believe all of
them can provide different results than literals in some cases.

YItz

On Sat, Oct 8, 2016 at 10:27 PM, David Feuer <david.feuer at gmail.com> wrote:
> The current Read instances for Float and Double look pretty iffy from an
> efficiency standpoint. Going through Rational is exceedingly weird: we
have
> absolutely nothing to gain by dividing out the GCD, as far as I can tell.
> Then, in doing so, we read the digits of the integral part to form an
> Integer. This looks like a detour, and particularly bad when it has many
> digits. Wouldn't it be better to normalize the decimal representation
first
> in some fashion (e.g., to 0.xxxxxxexxx) and go from there? Probably less
> importantly, is there some way to avoid converting the mantissa to an
> Integer at all? The low digits may not end up making any difference
> whatsoever.
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161010/e0a71faa/attachment.html>