Python Why do 0.1 and 1/10 work but 0.3-0.2 doesn't?

[.Scott]

Which way of displaying the result is more useful most of the time–0.1 or 0.09999999999999998? The same calculation in Excel, APL, Mathematica, Wolfram Alpha, Desmos, and, I would expect, most user-centric software, the result is rendered as 0.1. Why? Because most people don't care that the computer approximates 0.3-0.2 as 0.09999999999999998.

Note that both 0.09999999999999998 and 0.1 are rounded results. Neither is the exact representation of the computer's result from calculating 0.3-0.2. As mentioned in the Python documentation, displaying the exact result wouldn't be very useful to most people, so it displays a rounded result. The question is why round to 16 decimal places instead of, say, 7 or 10, by default?

There is more to it than "most useful most of the time". If you are going to go with 7 or 10 digits, it is important that you document that and that programmers know what it is. By defaulting to the full precision of the floating point encoding, you are setting a rule that is easy to recognize and easy to keep track of.

If you wanted to use a different number, I might go with 2 places to the right of the decimal. Aside being great for US currency, it would also be enough of a nuisance that Python programmers would quickly figure out how to be explicit about the displayed decimal precision.

One of the primary uses of the default precision is in writing debug code - code added to the code in the course of tracking down a bug - then soon deleted. In that case, defaulting to the full precision of the floating point encoding is perfect.

 

[vela]

And for a user interface for programmers, I think this is perfectly reasonable.

Just to be clear, I'm not saying either choice is inherently right or wrong. You think the choice is reasonable. I understand your reasons, but I just don't agree with them. Likewise, I'm sure you don't agree with my reasons that fewer digits would be a better default. Either way, it's just our opinions.

I just see this in a similar vein to another topics about Python that came up awhile ago. Someone considered Python a terrible language because it didn't require strong typing of variables. How dare someone use a computer without understanding the different ways computers represent numbers! And you rightly pointed out that it was a feature, not a bug, and has saved you a lot of time not having to cater unnecessarily to the machine.

 

[PeterDonis]

You think the choice is reasonable. I understand your reasons, but I just don't agree with them.

I understand that, but to me your disagreement appears to be based on a belief that Python source code and the Python interactive prompt are a user interface for average users instead of programmers. If that is the basis for your disagreement, I think you should reconsider what Python source code and the Python interactive prompt are actually for. I don't disagree with you if you are describing what you think a user interface for average users should do. I just don't think such requirements are appropriate for Python source code or the Python interactive prompt, since those aren't a user interface for average users.

If you actually believe a user interface for programmers should work the way you are claiming, then we have a much more fundamental disagreement and I don't find your arguments at all convincing. Your basic complaint seems to be that Python's approach is "computer centric", but that's exactly what a user interface for programmers should be.

Either way, it's just our opinions.

I don't think the statement that Python source code and the Python interactive prompt are user interfaces for programmers is a matter of opinion.

 

[jbriggs444]

As a programmer or a troubleshooter, I want a print statement that tells the truth about the internal value of a variable or of an expression. I will settle for 16 decimal digits since that is a reasonable match for the resolution of the underlying binary data. But I would not appreciate output that leads me accept an answer that tosses away the low order 19 or 20 bits of the actual result (as opposed to the "mathematically correct" result).

If I am dealing with discrepancies at about machine epsilon, I'll probably be looking for binary output. But for quick and dirty stuff a few orders of magnitude above machine epsilon, it would be nice for the print statement to lend a hand by default.

I started on a Texas Instruments SR51. So I know about guard digits. They are nice. The SR51 computed with, but did not display, three low order decimal "guard digits". But there is a difference between the user of a handheld calculator and the programmer of a Python application.

 

[anorlunda]

Haven't we flogged this topic to death yet?

 

[Ibix]

Haven't we flogged this topic to death yet?

I think it's machine esilon away from death and, due to finite precision arithmetic, it always will be...

 

[PeterDonis]

Thread closed for moderation.

 

[PeterDonis]

After moderator review, the thread will remain closed as the topic has been sufficiently discussed and the OP is long gone. Thanks to all who participated!