|Syntactic Confectionery Delight|
Re^8: Variables are automatically rounded off in perl (values)by tye (Sage)
|on Jul 25, 2016 at 21:43 UTC||Need Help??|
You link to two examples where stringification happened for subtle reasons. Neither of those appear to be situations where loss of precision would have been caused.
I think I made it clear in the update that one-to-one mapping i.e. identity is important
Sorry, no, one-to-one mapping and identity are not very useful with floating point values. That is why people soon realize that '==' is pretty much useless with floating point values.
Consider that you have $foo and $bar where "$foo" eq "$bar". What are the odds that $foo and $bar represent truly distinct values vs. that they represent what should be the same value that are only different because they were calculated via different means? The odds are astronomically in favor of the 2 values actually being inaccurate representations of the same value. So the current stringification is more likely to provide accurate identification than a full-accuracy stringification.
I can't say I've ever seen memoization done based on a floating point input. Memoization makes sense when you are going to have a fairly small number of different input sets. Where the same input values are likely to repeat in subsequent calculations. Such seems pretty unlikely with floating point values. Trying to think of a situations where such might legitimately be done, I mostly come up with cases where one of the inputs is technically floating point but should be restricted to a small set of possible values. A case where the slightly inaccurate stringification would actually be a benefit.
Similar, say you have $val where current Perl only stringifies to a few digits but a full-precision dump in base ten would require 17 digits. What are the odds that this value was achieved by combining values that only had a few digits vs that this value was obtained by calculations involving values not close to values having only a few digits vs this value is something like sqrt(0.8)*sqrt(1.8) where odd values were combined but the result really should be just 1.2, not 1.200000000000002? The middle case is extremely unlikely.