> Actually, 31.400000000000002 wasn't a true improvement over the earlier 31.4: > so long as we rely on the platform C to format floats, the output isn't > well-defined (the last digit or so can and will vary across boxes). I can't check right now, but I thought that this was pretty consistent across some common platforms? > I can certainly explain that this is so, and even why, but unsure > the tutorial is the right place for it. In any case the tutorial > shouldn't be giving examples whose output is platform-dependent. > For example, don't use 10 * 3.14, use 10 * 3.25. Want me to scour > the tutorial for all such cases? Are you serious? This is something that the newbie wou is in the least bit adventurous will run into anyway, so I don't think that not talking about this at all in the tutorial is fair or helpful. That just perpetuates the questions from newbies about "floating point is broken" -- since none of the tutorial examples prepare them for this. Since this is behavior that is ordinarily observed and perpetually perplexing, I think it *must* be treated in the tutorial. The tutorial doesn't have to have the full explanation -- maybe it's enough to say something like ``due to round-off errors you will sometimes see inexact results like 31.400000000000002; don't worry about this, you can use str() or "%g" (but not round()!) to strip redundant precision, and here's a URL for more info.'' Or maybe the full story can be an appendix. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4