On Aug 10, 2019, at 01:01, Richard Musil <risa2000x@gmail.com> wrote:
Andrew Barnert wrote:
Except that it doesn’t allow that. Using Decimal doesn’t preserve the difference between 1.0000E+3 and 1000.0, or between +12 and 12. Not to mention
but it preserves the exact precision and value, i.e. not a fraction is lost. This alone is worthy considering it as a feature update for me.
But float _already_ preserves the exact precision and value for the example you gave. The two strings are different string representations of the exact same float value, and will therefore give the exact same mathematical results with the exact same error bars. You’ve made it very clear that the exact precision and value isn’t what you’re interested in anyway, but the exact bytes of the text, so you can hash them. (You’ve then denied it, then made it very clear again, and gone around and around in circles, but that doesn’t change anything.)
The fact that a feature _can_ be misused isn’t a reason to reject it. But the fact that a feature will _almost always_* be misused is a different story.
Being able to dump the float as a float without losing any precision is the feature we are discussing here.
No, that’s the feature you already have for your example input, with float, today, and aren’t happy with. The feature we are discussing here is a way to do something that will, in that one specific example, give you back the exact same text, which is what you actually want. You either don’t have a problem (in which case you wouldn’t be here in the first place), or you have a problem that can’t be solved this way, and can’t even be solved in principle, but rather than accept that, you keep denying that you asked what you asked, and then pretending to have a different problem in hopes that different problem might be solved by the feature you asked for, so maybe the feature will be added so you can misuse it for what you really wanted.