**** BEGIN LOGGING AT Tue Jul 16 03:02:17 2019 Jul 16 12:21:08 Maxdamantus: GNU bc, at least when run with the -l (--mathlib) option, seems to return the expected results without doing anything special. I have known of bc for probably at least fifteen years but may have never seriously tried using it until now, after I redd the complete https://en.wikipedia.org/wiki/Bc_(programming_language) article. Jul 16 12:23:33 brolin_empey: okay, I didn't read your initial comment, but having read it now, the issue is not floating point, but binary representation of certain numbers. Jul 16 12:23:47 19:45:35 < brolin_empey> Floating point arithmetic is strange? With CPython 2.7.x on Windows NT on x86-64 (Intel Core 2), Linux on ARM on both the Nokia N900 and LG G5, 4.18+2.61 returns 6.789999999999999 or similar instead of 6.79 and 6.79+8.59 returns 15.379999999999999 or similar instead of 15.38 . Jul 16 12:24:16 neither 4.18 nor 2.61 is representable in binary without using recurrence. Jul 16 12:24:46 bc isn't limited to binary numbers, so does not suffer conversion issues. Jul 16 12:25:11 eg, when you add 4.18 and 2.61, it just does the addition in decimal. Jul 16 12:26:13 when you evaluate the expression `4.18` as a binary float, it comes up with a value that is not exactly 4.18, but is a close approximation to it, and the usual binary float printing mechanisms will figure out that that number is very close to the decimal "4.18" when printing. Jul 16 12:27:35 particularly, `4.18` in all of those languages will be interpreted instead as `4.17999999999999971578290569595992565155029296875` Jul 16 12:28:27 if you try writing that number in any of those languages, the printer will round it back to 4.18. Jul 16 12:30:15 note that IEEE-754 includes definitions of both "binary" floats and "decimal" floats, though programming languages usually only support binary. Jul 16 12:30:47 I think I may have known some of this stuff at least a decade ago but forgot it because I ended up being more of a sysadmin than a software developer. Jul 16 12:31:30 also note that decimal floats suffer the same issues, just with different sets of numbers. It happens that any number representable in binary is also representable in decimal, but a number like 1/3 is not representable in either. In decimal, you have to approximate 1/3 as something like `0.333333333333`, meaning (1/3)*3 will be something like `0.99999999999` Jul 16 12:31:59 (in base 3, that number is trivially representable as just `0.1`) Jul 16 12:36:45 fwiw, I don't think most developers understand this stuff. Jul 16 12:37:47 most developers live by the motto 'good enough [tm]' Jul 16 12:37:50 Maybe a lot of them are aware that `0.1 + 0.2` is not `0.3`, but I suspect most of those people think the problem is in the addition, not in the representation. Jul 16 12:39:50 (to clarify, the addition works perfectly fine there; the problem is that none of the numbers `0.1`, `0.2` or `0.3` are representable in binary, so it's a bit like interpreting `1/3` as `0.3333` and calculating that `(1/3)*3 = 0.9999`) Jul 16 13:02:29 a related point that I find annoying: people often seem to think that the solution to this problem is for programming languages to provide decimal floats rather than just binary floats, but in cases where it actually matters, you pretty much never want decimal floats. Jul 16 13:03:09 in cases where it matters, you usually want either some sort of fixed-point decimal, or arbitrary-precision decimal, or unbounded rationals. Jul 16 13:04:18 Floating point overall is just a convenient way of providing generic operations for handling approximate values. If you're not willing to approximate, you shouldn't be using floats. Jul 16 13:04:21 * Maxdamantus sleeps. Jul 16 13:04:43 there are doubles for more decimal points accuracy Jul 16 13:05:37 You're probably thinking of a form of decimal floating point, like IEEE-754 decimal64 or decimal128 or something. Jul 16 13:06:47 and my point applies: if those are useful to you, your cases should be handled just as well, and probably even better, by using fixed-point decimals. Jul 16 13:07:57 nah, just expanding byte count makes it goodier enough Jul 16 13:08:44 Unless you expand the byte count to infinity, you're still not going to get `0.1 + 0.2 == 0.3` Jul 16 13:08:56 * Maxdamantus really sleeps. Jul 16 13:09:11 ya, it's about setting your 'good enough' threshold **** ENDING LOGGING AT Wed Jul 17 02:59:57 2019