2

Why am I getting these results?

(+ 5.2   42.4   -1) 46.6
(+ 5.2   42.45   -1) 46.650000000000006

Couldn't the 2nd operation just output 46.65? Where does the 0000000000006 come from?

Drew
  • 75,699
  • 9
  • 109
  • 225
Quora Feans
  • 515
  • 3
  • 11
  • 3
    [What Every Programmer Should Know About Floating-Point Arithmetic](https://www.floating-point-gui.de/) explains everything very nicely. – phils Sep 01 '18 at 05:40
  • 2
    Also this :) https://0.30000000000000004.com/ – phils Sep 01 '18 at 06:11

2 Answers2

2

What you're seeing is a byproduct of binary floating-point arithmetic. Non-integer decimal values generally don't have a representation in binary floating point that is truly equal. For many applications the difference or inaccuracy in representation isn't important, so applications can leverage the flexibility and performance of that format. The Emacs manual discusses number representation in elisp: Numbers - GNU Emacs Lisp Reference Manual.

ebpa
  • 7,319
  • 26
  • 53
0

The most common floating point formats used on computers use binary.

so

5.2

in binary is

101.00110011001… 

This sequence goes on forever, and because it cannot go on forever will be an approximation.

Why is this?

10 has the factors 2 and 5, so all numbers n/m, where m has only the prime factors 2 and/or 5, can be represented without error. Other numbers will be rounder, e.g. n/3, n/7, n/9, n/11, n/12, n/13, n/14, n/15 n/17, … .

Binary is base 2 2 has the factors 2, so all numbers n/m, where m has only the prime factor 2, can be represented without error. So the the above list we add n/5, n/10, (n/15 is already included) n/20 etc.

You will note that it is only a few extra, but this can cause problems when numbers are displayed, and they are not what is expected.

Base 12 or 60 would be better, as they can be divided my more numbers, but still not all.