From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alexandre =?ISO-8859-1?Q?Fran=E7ois?= Garreau Newsgroups: gmane.emacs.help Subject: Re: (- 2.8 1.6) ; 1.1999999999999997 Date: Tue, 11 Feb 2020 02:50:42 +0100 Message-ID: <4431552.mgxCkZHi0q@galex-713.eu> References: <8736biywcn.fsf@ebih.ebihd> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="36522"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 11 02:52:18 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j1Kin-0009Ot-1W for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 11 Feb 2020 02:52:17 +0100 Original-Received: from localhost ([::1]:42266 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1Kim-00051g-1S for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 10 Feb 2020 20:52:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50988) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1Ki8-000518-6v for help-gnu-emacs@gnu.org; Mon, 10 Feb 2020 20:51:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j1Ki6-00040A-9G for help-gnu-emacs@gnu.org; Mon, 10 Feb 2020 20:51:35 -0500 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:56824 helo=galex-713.eu) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j1Ki5-0003of-T4 for help-gnu-emacs@gnu.org; Mon, 10 Feb 2020 20:51:34 -0500 Original-Received: from gal by galex-713.eu with local (Exim 4.92) (envelope-from ) id 1j1Khs-0003vh-7x; Tue, 11 Feb 2020 02:51:20 +0100 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:5884:8305::1 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:122397 Archived-At: Le mardi 11 f=C3=A9vrier 2020, 02:31:56 CET Stefan Monnier a =C3=A9crit : > > (- 2.8 1.6) ; 1.1999999999999997 >=20 > 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. >=20 > 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". >=20 > > With the TI-84 Plus, > >=20 > > 2.8-1.6=3D1.2 >=20 > 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=20 in base 2, so it=E2=80=99s like 2.8 =3D (2.5 =3D #b10.1) + (0.25 =3D #b0.01= ) - (0.05 =3D=20 =E2=80=A6)=E2=80=A6 etc. while 1.6 =3D (1.5 =3D #b1.1) + (0.1 =3D ~#b0.0001= =E2=80=A6) etc. and 1.2 =3D=20 (1.25 =3D #b1.05) - 0.05, etc. Base 2 is compatible with any base which is a power of 2 (2, 4, 16, etc.)=20 without rounding errors. We commonly day-to-day use base 10, which is=20 2=C3=975. So some numbers convert smoothly without rounding error (=E2=80= =9Ca half=E2=80=9D=20 translates in 0.5 in base 10, and 0.1 in base 2), other won=E2=80=99t ever:= =E2=80=9Ca=20 fivth=E2=80=9D is tailor-made to be easily expressed in base 10: 0.2, but i= t=20 *can=E2=80=99t* be expressed in base two (without rational numbers (eg.=20 fractions)). A good analogy to understand: in base 10, we can=E2=80=99t represent =E2=80= =9Ca third=E2=80=9D in=20 decimal notation (it gives some rounding like =E2=80=9C0.33333333=E2=80=A6= =E2=80=9D etc.), neither=20 it can in base 2 (because 3 is not a divisor of 2 nor of 10), but it *can*= =20 in base 12! so in base twelve 1/3 would simply be 1/4 (exactely like 4=20 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=20 some others. Some are more useful (base 12 have a lots of divisors),=20 others more common (base 10 since arabic numbers became widely used)=E2=80= =A6 and=20 in case of computers, base 2 is ubiquitous. You can=E2=80=99t make electro= nics=20 efficiently with a base higher than 2 (afair CCCP made a base 3 computer=20 once but it was more complex and more expensive). So everything, even=20 TI84+ is base 2. The fact they store and treat base10 floating numbers=20 helps for education, because you won=E2=80=99t see rounding errors and won= =E2=80=99t have=20 to learn about it. But with real efficient computers, that would be a wast= e=20 of both space and time. Space because to store a base 10 digit, in base=20 2, you anyway need 4 bits, that could store 16 different values (so you=20 waste 6 of them who won=E2=80=99t ever be used), slower because algorithm t= hat=20 would naturally apply to base 2 won=E2=80=99t apply and you will have to do= other=20 more complicated stuff (taking into account there are 6 possibilities every= =20 4 bits that you are wasting and not taking into account).