Re^7: Variables are automatically rounded off in perl (scientists)

Re: pPOK. I was thinking about things like this, though that's probably a bug in the module. In any case, bad design and bugs compound to make one hellish landscape. It's the difference between "things just work" and "things just don't work".

Re: one grain of sand. I think I made it clear in the update that one-to-one mapping i.e. identity is important, even if the magnitude isn't. I don't hear you refuting that.

Basically, there are two desirable properties to have:

exact calculations, free of accumulating errors ("grains of sand"). Perl NV aka double cannot guarantee that, period. Feed complainers => -Mbigrat.
round-tripping conversions. That can be guaranteed! And should. "0.1" -> 0.1 -> "0.1" is about shortest roundtrip, no truncation is necessary.

Finally, Re: cut and paste computing. Absolutely! Take a printed paper and run those numbers. Repeatability is the cornerstone. If you say you run statistics on IEEE doubles, but your data does not compute, someone will be upset.

Comment on Re^7: Variables are automatically rounded off in perl (scientists)

Replies are listed 'Best First'.
Re^8: Variables are automatically rounded off in perl (values) by tye (Sage) on Jul 25, 2016 at 21:43 UTC
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. - tye	[reply] [d/l] [select]
Re^9: Variables are automatically rounded off in perl (assumptions) by oiskuu (Hermit) on Jul 25, 2016 at 22:16 UTC
When I choose doubles for whatever the task is (say computing pretty fractals), I expect the full precision of the underlying apparatus. Granted, stringification is not very expedient in this case, and hence, even the more cause for nasty surprises. As for what are the odds that truncation accidentally leads to correct result? Sorry but no, hell no, I do not need anybody guessing (poorly) what the result might have been. I just need the calculations done as programmed. Edit. I'll add this little anecdote about astronomical odds. Two friends are idly looking out the window; the street is all but empty save for occasional traveler passing. One says, "hey, I'll bet a penny for your watch that the next one hundred passers-by are all men!" His mathematically astute friend replies, "taken! You'd better have that coin ready, because the odds for that are, quite, a-stronomical!" Very soon after, the first person slyly remarks, "What do you think, isn't that a soldiers' marching song we hear approaching?"	[reply]