How is that not a bug? We should be able to read back floats On Monday, October 10, 2016, David Feuer <david.fe...@gmail.com> wrote:
> It doesn't, and it never has. > > On Oct 10, 2016 6:08 PM, "Carter Schonwald" <carter.schonw...@gmail.com > <javascript:_e(%7B%7D,'cvml','carter.schonw...@gmail.com');>> wrote: > >> Read should accept exactly the valid source literals for a type. >> >> On Monday, October 10, 2016, David Feuer <david.fe...@gmail.com >> <javascript:_e(%7B%7D,'cvml','david.fe...@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.schonw...@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.fe...@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" <g...@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.fe...@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@haskell.org >>>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> > >>>>> >>>>> >>>>>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
