aeson and dlist in HP 2013.4.0.0

[Carter Schonwald]

I'm looking at the scientific package, and I thought to myself "huh, it
doesn't seem to normalize the numbers to scientific notation"

it has the right semantics for how printing and operations *mean*, but it
doesn't seem to internally keep them as "normalized" floats.

heres a snippet of a ghci transcript to illustrate this

Prelude Data.Scientific> coefficient $ scientific 1000 2
1000
Prelude Data.Scientific> coefficient $ scientific 1 2
1
Prelude Data.Scientific> scientific 1000 2
100000.0
Prelude Data.Scientific> scientific 100 3
100000.0
Prelude Data.Scientific> coefficient $ scientific 10 4
10
Prelude Data.Scientific> scientific 10 4
100000.0
Prelude Data.Scientific> scientific 10 4 == scientific 1 5
True

shoudn't an "exact" model of scientific notation format numbers keep them
in normalized form?  (ie clip the trailing zeros and such)





On Wed, Nov 27, 2013 at 2:28 PM, Mark Lentczner <mark.lentczner at gmail.com>wrote:

> Okay - to put a concrete proposal on this:
>
> 1) Include dlist-0.6, which would have the additions that Sean L. has
> proposed
> 2) Include scientific as package
> 3) Include an aeson that is updated to use the above two packages (and
> won't use blaze-builder)
>
> ​*Sean* - do you have a time frame for such changes?
> *Bas* - do you feel the API of scientific is solid enough to go into the
> platform? Are you willing to commit to the stability needs of the
> platform(*)
> *Bryan* - are you ready to turn out an aeson version that uses the above
> once they are out?
>
> *Everyone else* - After all the conversations, do we feel the rough
> consensus is to go ahead with these. In particular the changes that Sean
> proposed for dlist, and the inclusion of scientific.
>
> I realize this is Thanksgiving week in the U.S. - but let's hope we can
> come to a close on this by next Tuesday - Dec 3rd. Preferably sooner!
>
> - Mark
>
> (*): Meaning, the package would remain backward compatible for a few revs
> with ample deprecation time before altering APIs that would break code --
> even through major version number changes.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131127/c476d391/attachment.html>