> Well, even if for comparisons we treat floats as if they were exact, > for other purposes I want to keep the association of "float" with > "inexact" and "int/long" with "exact", and I'd rather not return an > "exact" result from an operation involvin an "inexact" operand. Agreed. > (The alternative, introducing exactness as a separate concept from > representation, is better in theory but in practice just complicates > matters needlessly.) Also agreed. However, I'm thinking less about exactness than I am about choosing the more accurate of two possible representations for the result. For example, in principle it should be possible to guarantee that x+0.0 == x for all numeric values of x. The unanswered question in my mind is whether such a guarantee carries other undesirable properties along with it. Incidentally, right now I am leaning toward the believe that such a guarantee *does* carry other undesirable properties along with it. For example, consider 0L + 1e300. It is clear that in principle, no accuracy is lost by returning the result of this addition as a long. It is equally clear that in practice, it would be very slow.
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