search

basvandijk / scientific

Arbitrary-precision floating-point numbers represented using scientific notation
BSD 3-Clause "New" or "Revised" License
73 stars 40 forks source link

Normalize in the Lift instance #85

Open treeowl opened 2 years ago

treeowl commented 2 years ago

Normalizing in the Lift instance can reduce normalization work in generated splices.

phadej commented 2 years ago

I'm not sure about this. Scientific values are not normalized, and that observably affects results (e.g. aeson serialization).

So I'm hesitant merging this (and also making a release of scientific which normalizes on construction, which would be otherwise good).

treeowl commented 2 years ago

@phadej my impression was that normalization wasn't supposed to change meaning. Was that wrong?

phadej commented 2 years ago

@treeowl It does change some "meaning", as base10exponent (and coefficient) are public functions:

Prelude Data.Aeson Data.Scientific> encode $ scientific 100 (-2)
"1.0"
Prelude Data.Aeson Data.Scientific> encode $ normalize $ scientific 100 (-2)
"1"

If Scientific is always normalized (like Rational), then that won't be an issue. And I think normalizing would be fine; but i'm not 100% sure.

Therefore I didn't proceed further with always normalized scientific. That needs a proper thought. But in that case this PR won't be needed.

TL;DR normalizing in Lift but not-normalizing on construction feels to be bad thing. For now, people who want this can normalize before lifting.