4 ms·
If you write literals such as 0xa.bp-3, 1/3 or 22/7, why would those be allowed to throw out precision for speed? (That hex literal is valid C++17; the fraction
by Someone 5y ago
If you write literals such as 0xa.bp-3, 1/3 or 22/7, why would those be allowed to throw out precision for speed? (That hex literal is valid C++17; the fractions aren’t literal in the standards, but IMO are literals in human heads)
⇒ If you think the “sensible default behavior is to preserve precision“ I think you would have to call for (at least) rational as the default non-integer integral type. (If you think of √2 as a literal, it gets more complicated. In the end, you might have to use a representation that’s similar to that used in computer algebra systems)
Edit: you could also require constants that do have an exact representation in your floating point format. That would be annoying, too, though, but maybe not too annoying if you had a way to specify “the number closest to this one”, say by requiring one to write ~2.1~ instead of 2.1
- lmm 5y ago> If you write literals such as 0xa.bp-3, 1/3 or 22/7, why would those be allowed to throw out precision for speed? (That hex literal is valid C++17; the fractions aren’t literal in the standards, but IMO are literals in human heads) IMO decimal rounding of those fractions, while not ideal, is a lot more understandable to a typical person. If 1/3 * 3 = 0.99999999999999999 that's annoying, but not crazy in the same way that the floating-point equivalent is.