3 ms·

Couldn't resist checking what math.h does for floats and doubles on godbolt, it returns slightly above 9, but curiously not exactly equal to any answer in that

by OskarS 1y ago

Couldn't resist checking what math.h does for floats and doubles on godbolt, it returns slightly above 9, but curiously not exactly equal to any answer in that list [1]. Maybe not that surprising, these transcendental functions are always iffy in the last digits. [1]: https://godbolt.org/z/dK85Eq8r6 https://godbolt.org/z/dK85Eq8r6

masfuerte 1y ago
CORE-MATH provides correctly rounded transcendental functions. (Though that doesn't mean that this calculation will return exactly 9. And I haven't tried it.) https://core-math.gitlabpages.inria.fr/ https://core-math.gitlabpages.inria.fr/
chongli 1y ago
I would be really surprised if any physical calculator used binary floating point numbers instead of binary-coded decimal. The appearance of repeating bits even for relatively simple decimal numbers like 0.1 is likely to confuse and annoy a calculator user expecting an exact answer.
- OskarS 1y ago
  I would assume most basic calculators use regular floating point circuits, and then just round aggressively for the display.
  - inejge 1y ago
    Cheap calculators use microcontroller-like CPUs which simply have no room for floating-point hardware. BCD or fixed-point integers in software are much cheaper and simpler.
  - kragen 1y ago
    Microcontrollers with floating point hardware are very expensive (60¢ and up) compared to microcontrollers without (3¢), and since the 01980s, software floating point has been plenty fast enough to use in pocket calculators, even on the slowest microcontrollers available. To be somewhat concrete, on amd64 with valgrind --tool=callgrind my non-BCD decimal fixed-point RPN calculator program https://gitlab.com/kragen/bubbleos/tree/master/yeso/rpncalc.c https://gitlab.com/kragen/bubbleos/tree/master/yeso/rpncalc.... compiled for the console (rpncalc_linux.c) takes 228,141 instructions to process the input "2 3q" from the keyboard, and 229,824 instructions to process the input "2 3/q", an additional 1,683 instructions for the division, mostly to display the result. Division is probably the worst case for regular arithmetic. An additional division operation takes another 1,601 instructions. A subtraction instead takes 1,563. On an 8-bit processor like a PIC or AVR, you need to run more instructions to do the same work, but it's typically maybe a factor of 8 for data processing and less for things like looping. So we're talking about maybe 10,000 instructions per keystroke, probably less. On a 16MHz 1T microcontroller, that's less than a millisecond. You might think that if the microcontroller doesn't have space for floating-point circuitry it also doesn't have space for enough memory for software floating point, but that would be wrong. My decimal floating point library is 1204 bytes (≈602 instructions) compiled for AVR, and the calculator UI logic is 2134 bytes (≈1067 instructions). This fits in all but the smallest microcontrollers. Like, it doesn't quite fit in an ATTiny25.
avipars 1y ago
chalk it up to floating point accuracy

by OskarS 1y ago

masfuerte 1y ago

CORE-MATH provides correctly rounded transcendental functions. (Though that doesn't mean that this calculation will return exactly 9. And I haven't tried it.) https://core-math.gitlabpages.inria.fr/ https://core-math.gitlabpages.inria.fr/

chongli 1y ago

I would be really surprised if any physical calculator used binary floating point numbers instead of binary-coded decimal. The appearance of repeating bits even for relatively simple decimal numbers like 0.1 is likely to confuse and annoy a calculator user expecting an exact answer.

OskarS 1y ago
I would assume most basic calculators use regular floating point circuits, and then just round aggressively for the display.
- inejge 1y ago
  Cheap calculators use microcontroller-like CPUs which simply have no room for floating-point hardware. BCD or fixed-point integers in software are much cheaper and simpler.
- kragen 1y ago
  Microcontrollers with floating point hardware are very expensive (60¢ and up) compared to microcontrollers without (3¢), and since the 01980s, software floating point has been plenty fast enough to use in pocket calculators, even on the slowest microcontrollers available. To be somewhat concrete, on amd64 with valgrind --tool=callgrind my non-BCD decimal fixed-point RPN calculator program https://gitlab.com/kragen/bubbleos/tree/master/yeso/rpncalc.c https://gitlab.com/kragen/bubbleos/tree/master/yeso/rpncalc.... compiled for the console (rpncalc_linux.c) takes 228,141 instructions to process the input "2 3q" from the keyboard, and 229,824 instructions to process the input "2 3/q", an additional 1,683 instructions for the division, mostly to display the result. Division is probably the worst case for regular arithmetic. An additional division operation takes another 1,601 instructions. A subtraction instead takes 1,563. On an 8-bit processor like a PIC or AVR, you need to run more instructions to do the same work, but it's typically maybe a factor of 8 for data processing and less for things like looping. So we're talking about maybe 10,000 instructions per keystroke, probably less. On a 16MHz 1T microcontroller, that's less than a millisecond. You might think that if the microcontroller doesn't have space for floating-point circuitry it also doesn't have space for enough memory for software floating point, but that would be wrong. My decimal floating point library is 1204 bytes (≈602 instructions) compiled for AVR, and the calculator UI logic is 2134 bytes (≈1067 instructions). This fits in all but the smallest microcontrollers. Like, it doesn't quite fit in an ATTiny25.

avipars 1y ago

chalk it up to floating point accuracy