(- 2.8 1.6) ; 1.1999999999999997

(- 2.8 1.6) ; 1.1999999999999997

[Emanuel Berg via Users list for the GNU Emacs text editor]

What's this?

    (- 2.8 1.6) ; 1.1999999999999997

With the TI-84 Plus,

    2.8-1.6=1.2

Normally I'm all pro-Lisp but here...

Actually zsh also reports

    echo $(( 2.8 - 1.6 )) # 1.1999999999999997

so perhaps some CPU (ALU) thing?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: (- 2.8 1.6) ; 1.1999999999999997

[tomas]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Mon, Feb 10, 2020 at 10:18:48PM +0100, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> What's this?
> 
>     (- 2.8 1.6) ; 1.1999999999999997
> 
> With the TI-84 Plus,
> 
>     2.8-1.6=1.2
> 
> Normally I'm all pro-Lisp but here...

Those numbers aren't exactly representable as binary fractions
(2.8 = 14/5, 1.6 = 8/5). So things like this happen. It's not
Lisp, but an artifact of the underlying representation (as
binary "floats" with limited precision).

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: (- 2.8 1.6) ; 1.1999999999999997

[Joost Kremers]

On Mon, Feb 10 2020, Emanuel Berg via Users list for the GNU Emacs 
text editor wrote:
> What's this?
>
>     (- 2.8 1.6) ; 1.1999999999999997
>
> With the TI-84 Plus,
>
>     2.8-1.6=1.2
>
> Normally I'm all pro-Lisp but here...
>
> Actually zsh also reports
>
>     echo $(( 2.8 - 1.6 )) # 1.1999999999999997

joost@Swift:~$ clojure
Clojure 1.9.0
user=> (- 2.8 1.6)
1.1999999999999997
user=> (+ 0.1 0.2)
0.30000000000000004
user=> <C-d>
joost@Swift:~$ python
Python 2.7.17 (default, Nov  7 2019, 10:07:09)
[GCC 7.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> 2.8 - 1.6
1.1999999999999997
>>> 0.1 + 0.2
0.30000000000000004
>>> <C-d>
joost@Swift:~$ 

> so perhaps some CPU (ALU) thing?

It's a binary thing, and it's well-known:

https://floating-point-gui.de/

-- 
Joost Kremers
Life has its moments

Re: (- 2.8 1.6) ; 1.1999999999999997

[Emanuel Berg via Users list for the GNU Emacs text editor]

Joost Kremers wrote:

>> so perhaps some CPU (ALU) thing?
>
> It's a binary thing, and it's well-known

Still, one would think that even an
approximation as base as involving
_integers only_ would arrive at the conclusion,
that it is even more well-known that
2.8-1.6=1.2 just as the TI-84 Plus suggests.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: (- 2.8 1.6) ; 1.1999999999999997

[Stefan Monnier]

>     (- 2.8 1.6) ; 1.1999999999999997

Emacs Lisp, like most common programming language doesn't support
rational numbers (and even less real numbers, which can't be faithfully
represented in a computer) but only floating point numbers.  And like
most programming languages it uses the standard IEEE representation
supported natively by most CPUs.  This representation can't represent
2.8 nor 1.6 (and nor 1.2) exactly.

It so happens that "the representable number closest to 2.8" minus "the
representable number closest to 1.6" is not equal to "the representable
number closest to 1.2".

> With the TI-84 Plus,
>
>     2.8-1.6=1.2

IIUC those calculators used a decimal floating point representation,
which suffers from the same kinds of problems of course, but works
better in this specific case.


        Stefan

Re: (- 2.8 1.6) ; 1.1999999999999997

[Alexandre François Garreau]

Le mardi 11 février 2020, 02:31:56 CET Stefan Monnier a écrit :
> >     (- 2.8 1.6) ; 1.1999999999999997
> 
> Emacs Lisp, like most common programming language doesn't support
> rational numbers (and even less real numbers, which can't be faithfully
> represented in a computer) but only floating point numbers.  And like
> most programming languages it uses the standard IEEE representation
> supported natively by most CPUs.  This representation can't represent
> 2.8 nor 1.6 (and nor 1.2) exactly.
> 
> It so happens that "the representable number closest to 2.8" minus "the
> representable number closest to 1.6" is not equal to "the representable
> number closest to 1.2".
> 
> > With the TI-84 Plus,
> > 
> >     2.8-1.6=1.2
> 
> IIUC those calculators used a decimal floating point representation,
> which suffers from the same kinds of problems of course, but works
> better in this specific case.

To add precision: IEEE (hence most computers) store floating point number 
in base 2, so it’s like 2.8 = (2.5 = #b10.1) + (0.25 = #b0.01) - (0.05 = 
…)… etc. while 1.6 = (1.5 = #b1.1) + (0.1 = ~#b0.0001…) etc. and 1.2 = 
(1.25 = #b1.05) - 0.05, etc.

Base 2 is compatible with any base which is a power of 2 (2, 4, 16, etc.) 
without rounding errors.  We commonly day-to-day use base 10, which is 
2×5.  So some numbers convert smoothly without rounding error (“a half” 
translates in 0.5 in base 10, and 0.1 in base 2), other won’t ever: “a 
fivth” is tailor-made to be easily expressed in base 10: 0.2, but it 
*can’t* be expressed in base two (without rational numbers (eg. 
fractions)).

A good analogy to understand: in base 10, we can’t represent “a third” in 
decimal notation (it gives some rounding like “0.33333333…” etc.), neither 
it can in base 2 (because 3 is not a divisor of 2 nor of 10), but it *can* 
in base 12! so in base twelve 1/3 would simply be 1/4 (exactely like 4 
hours (or pennies or forgot how it worked) is already a third of a day).

So each base can turns out to be pretty arbitrary and incompatible with 
some others.  Some are more useful (base 12 have a lots of divisors), 
others more common (base 10 since arabic numbers became widely used)… and 
in case of computers, base 2 is ubiquitous.  You can’t make electronics 
efficiently with a base higher than 2 (afair CCCP made a base 3 computer 
once but it was more complex and more expensive).  So everything, even 
TI84+ is base 2.  The fact they store and treat base10 floating numbers 
helps for education, because you won’t see rounding errors and won’t have 
to learn about it.  But with real efficient computers, that would be a waste 
of both space and time.  Space because to store a base 10 digit, in base 
2, you anyway need 4 bits, that could store 16 different values (so you 
waste 6 of them who won’t ever be used), slower because algorithm that 
would naturally apply to base 2 won’t apply and you will have to do other 
more complicated stuff (taking into account there are 6 possibilities every 
4 bits that you are wasting and not taking into account).

Re: (- 2.8 1.6) ; 1.1999999999999997

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

>>     (- 2.8 1.6) ; 1.1999999999999997
>
> Emacs Lisp, like most common programming
> language doesn't support rational numbers
> (and even less real numbers, which can't be
> faithfully represented in a computer) but
> only floating point numbers. And like most
> programming languages it uses the standard
> IEEE representation supported natively by
> most CPUs. This representation can't
> represent 2.8 nor 1.6 (and nor 1.2) exactly.
>
> It so happens that "the representable number
> closest to 2.8" minus "the representable
> number closest to 1.6" is not equal to "the
> representable number closest to 1.2".
>
>> With the TI-84 Plus,
>>
>>     2.8-1.6=1.2
>
> IIUC those calculators used a decimal
> floating point representation, which suffers
> from the same kinds of problems of course,
> but works better in this specific case.

Sure seems like it :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: (- 2.8 1.6) ; 1.1999999999999997

[Bruno Félix Rezende Ribeiro]

[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]

Hello Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Emacs Lisp, like most common programming language doesn't support
> rational numbers (and even less real numbers, which can't be faithfully
> represented in a computer) but only floating point numbers.

I find this characterization a little bit misleading, and I know it’s
common jargon in computer science backed up by the specialized
literature and such, but I’d like to express my view on the matter.

Rigorously speaking there is no such thing as floating pointing
/numbers/ as there is no such thing as roman /numbers/ or even Arabic
decimal /numbers/.  All of those are /numerals/, that is, sequence of
symbols which represent (true) /numbers/.

All floating point numerals demonstrably represent rational numbers,
which are by definition also real numbers.  Therefore, Emacs support
arithmetic on some (finitely many) rational and real numbers.  Not all
rational numbers can be represented by floating point numerals, though.

Yet, all rational numbers can be represented by pairs of arbitrarily
large integers, which Emacs support (theoretically) by means of its
built-in Calc library.

Regarding irrational numbers, computers can faithfully represent any one
that is computable.  There are infinitely many of those (countably many,
still).  For instance, they may be represented by procedures that take
an arbitrarily large natural number =n= and outputs a rational number
that differs from the irrational number they represent in less than
=10^-n= units.  Being Lisp a Turing-complete language, Emacs can
represent all such real numbers.  To write an Emacs generalized real
number arithmetic package remains as an (exciting?) open exercise for
the free software community.

In my view and experience the rigor and distinctions I tried to convey
above make all the difference in truly understanding the Math-computer
and number-numeral dichotomy that seems to confuse so many programmers.


> IIUC those calculators used a decimal floating point representation,
> which suffers from the same kinds of problems of course, but works
> better in this specific case.

Trivially, "decimal" floating point numerals (of sorts) would still be a
super-set of binary floating point numerals if independent integer
exponents were allowed for the denominator factors of 2 and 5.


-- 
Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
<http://oitofelix.freeshell.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]