Skip to content

Conversation

@treeowl
Copy link

@treeowl treeowl commented Jan 21, 2022

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

Normalizing in the `Lift` instance can reduce normalization work in generated splices.
@phadej
Copy link
Collaborator

phadej commented Jan 21, 2022

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
Copy link
Author

treeowl commented Jan 21, 2022

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

@phadej
Copy link
Collaborator

phadej commented Jan 21, 2022

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants