[Guido] > ... > Not clear at all. ABC did this, and we found that a common problem > was that a program doing numeric stuff would run very slowly (i.e. the > opposite of failing noisily). Time for my yearly repetition of that I believe that, at least for me, many (perhaps most, but not all) of the surprises in ABC were due to that "floating-point literals" (like 6.02e23) were also treated as exact rationals. > ... > The problem with a fuzz variable is that there's only one, and > library modules may end up fighting over the right value for what > they are trying to accomplish. Making it a per-module variable > causes the opposite set of problems. Knuth defines a much more sophisticated notion of "fuzzy comparison" for floats (TAoCP Vol 2). That never caught on either. I'm never clear on what people think they're *solving* with suggestions like these -- binary floating-point is so horrendously at odds with "common sense" regardless that it solves nothing. In APL there was a particular reason for it, in order to create arrays of booleans from whole-array comparison operators efficiently, but that didn't make it a useful *scalar* gimmick there either, and in my brief APL days the damn fuzz destroyed more careful numeric algorithms than it helped for that reason. > I'm all for adding rationals to the language -- but I'd like them > segregated until we have a lot more experience with how they behave. They behave most like precocious children with voracious appetite <wink>.
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