* Re: (- 2.8 1.6) ; 1.1999999999999997
2020-02-11 1:31 ` Stefan Monnier
@ 2020-02-11 1:50 ` Alexandre François Garreau
2020-02-11 1:55 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-04-07 14:00 ` Bruno Félix Rezende Ribeiro
2 siblings, 0 replies; 8+ messages in thread
From: Alexandre François Garreau @ 2020-02-11 1:50 UTC (permalink / raw)
To: help-gnu-emacs; +Cc: Stefan Monnier
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).
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: (- 2.8 1.6) ; 1.1999999999999997
2020-02-11 1:31 ` Stefan Monnier
2020-02-11 1:50 ` Alexandre François Garreau
@ 2020-02-11 1:55 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-04-07 14:00 ` Bruno Félix Rezende Ribeiro
2 siblings, 0 replies; 8+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-02-11 1:55 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: (- 2.8 1.6) ; 1.1999999999999997
2020-02-11 1:31 ` Stefan Monnier
2020-02-11 1:50 ` Alexandre François Garreau
2020-02-11 1:55 ` Emanuel Berg via Users list for the GNU Emacs text editor
@ 2020-04-07 14:00 ` Bruno Félix Rezende Ribeiro
2 siblings, 0 replies; 8+ messages in thread
From: Bruno Félix Rezende Ribeiro @ 2020-04-07 14:00 UTC (permalink / raw)
To: Stefan Monnier; +Cc: help-gnu-emacs
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread