Clear questions and runnable code
get the best and fastest answer
Re^6: Variables are automatically rounded off in perl (people)by tye (Sage)
|on Jul 25, 2016 at 19:40 UTC||Need Help??|
Yes, you list 3 roles where somebody should specify how many digits that they want output.
How about the rocket scientist for whom that grain of sand on the beach represents the difference between orbital insertion and having the new crater named after them?
So, if a rocket scientist is taking the default stringification from one set of complex calculations that require extreme precision and then just pasting those into some other set of complex calculations that require extreme precision and is oblivious to the loss of precision that resulted, then they aren't very good at their job. I've actually worked for rocket scientists (doing numerical calculations for them -- though, I was dealing with trying to predict cracks in rocket fuel, not orbital mechanics).
So, when sending a craft to some distant part of space, the things you measure and control are the weight of the craft and payload, the force provided by the various engines, the duration of a burn, the orientation of the craft when the burn happens. None of those are things where you have anything close to even 15 digits of accuracy.
Calculations in orbital mechanics involve a lot of numerical methods for finding solutions. Those repeat a calculation over and over, adjusting values, searching for the solution, stopping when the accuracy gets close enough. Such techniques are extremely unlikely to work if you are wanting 15 digits of accuracy and are using the 53-bit mantissa of a standard 'double' (especially when the calculations are as complicated as those of orbital mechanics). So I won't take your word that rounding some intermediate value in the middle of some rocket science calculation would be a fatal flaw.
How about the dozens that have come here every year for the last decade only to be told that if they want understand perl's confusing default output they've got to go away and read
I've only seen one person complain about Perl's default output being truncated. I've seen several people complain about Perl's default output not being as truncated as they expected. I've seen several people complain about how the use of '==' on floating point values is so exacting as to be nearly useless. I've seen several people note that using 'eq' instead of '==' "fixes" the reported problem, well, until you get your way, of course.
So, your stance solves 1 person's problem. It exacerbates the problem for the several people in the second group. It removes an easy work-around for the third problem.
Well, "print 0.1" producing "0.1" is also producing a lie. The value is not actually 0.1. So, having "print 0.1" actually produce "0.10000000000000001" (which is also a lie, just less of one) would force people to understand the limits of floating point even sooner. Despite that benefit, I don't believe it would be the best trade-off for Perl.
Your stance would have something as trivial as "print 0.1+0.2" produce 17 digits of noise.
Just who are these unnamed "people"
They are similar to the unamed people you claim come to PerlMonks complaining about the default output precision. Like the one actual case of such that I've seen (the starter of this thread), they usually don't say much of anything about what they were trying to do. We have nearly no clue (at this time) how that author got a value of 3335.9999999999995 nor why they think they need that value reported to 17 digits of accuracy (but don't want to specify that requirement). I'd actually like to know some of that back story. It might even convince me that I'm wrong.
But I can share an example of a recent case where I was happy to be ever so slightly (more) lied to by default.
I measure various types of durations using wrappers around high-resolution timers where the underlying details of the timer vary between platforms. But it turns out that all of the platforms I've done this on have high-resolution timers that measure in some negative power of 10 of seconds. They don't all agree on the power. So some systems give me durations in milliseconds. Some in microseconds. Some in 10s or 100s of microseconds. Some that I haven't used recently actually only gave me hundredths of seconds. So, when I add up some small number of durations (or subtract a few high-resolution times), I am thankful to get told only a few digits after the decimal point when I report the total number of seconds.
Actually figuring out how many digits to ask for in order to get this behavior even if I were to add up thousands of such values is not trivial.
So, even though these systems are all binary systems, it turns out that, since they were designed by humans, they have a strong bias toward powers of 10.
It is just extremely common for people to deal with a reasonably small number of values each of which has a reasonably small number of digits after each decimal point. It is nice to let such common (often informal) data sets to be manipulated using mundane addition and subtraction and get results that look as expected. In such situations, the person is not happy to suddenly have a dozen or so '0's or '9's show up on the end of some of their output values.