Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Re^8: Variables are automatically rounded off in perl (values)

by tye (Sage)
on Jul 25, 2016 at 21:43 UTC ( #1168510=note: print w/replies, xml ) Need Help??

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

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        

Replies are listed 'Best First'.
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?"

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1168510]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (6)
As of 2020-10-29 12:09 GMT
Find Nodes?
    Voting Booth?
    My favourite web site is:

    Results (270 votes). Check out past polls.