Reading floating point

[Carter Schonwald]

Read should accept exactly the valid source literals for a type.

On Monday, October 10, 2016, David Feuer <david.feuer at gmail.com> wrote:

> What does any of that have to do with the Read instances?
>
> On Oct 10, 2016 1:56 PM, "Carter Schonwald" <carter.schonwald at gmail.com
> <javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>> wrote:
>
>> The right solution is to fix things so we have scientific notation
>> literal rep available.  Any other contortions run into challenges in
>> repsentavility of things.  That's of course ignoring denormalized floats,
>> infinities, negative zero and perhaps nans.
>>
>> At the very least we need to efficiently and safely support everything
>> but nan. And I have some ideas for that I hope to share soon.
>>
>> On Monday, October 10, 2016, David Feuer <david.feuer at gmail.com
>> <javascript:_e(%7B%7D,'cvml','david.feuer at gmail.com');>> wrote:
>>
>>> 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/97b8775c/attachment.html>