Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Chris Angelico <rosuav@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: What exactly is "exact" (was Clean Singleton Docstrings)
Date: Mon, 18 Jul 2016 15:48:50 +1000
Lines: 49
Message-ID: <mailman.69.1468820934.2307.python-list@python.org>
References: <nlmpl5$9l4$1@dont-email.me> <nlnl9m$j3b$1@ger.gmane.org> <mailman.137.1467963521.2295.python-list@python.org> <df9aaf24-394f-451a-9518-7e3a8dc67318@googlegroups.com> <nm6kbb$t6b$1@ger.gmane.org> <mailman.51.1468454075.21009.python-list@python.org> <7046c74e-e5ea-4dde-8847-8c556756a563@googlegroups.com> <5789B601.9000604@stoneleaf.us> <mailman.26.1468642801.2307.python-list@python.org> <9d2a0934-bf26-42a8-9bb2-e4e75b2d2ad3@googlegroups.com> <CAPTjJmq+VKdu7x_nzfP8fb=0EiAqWJO6_qKNsabQSnbBStyMsA@mail.gmail.com> <1468652038.1427719.667878897.460955C0@webmail.messagingengine.com> <mailman.28.1468652041.2307.python-list@python.org> <578a027c$0$1616$c3e8da3$5496439d@news.astraweb.com> <69d8d886-c18a-4c05-8bca-9a05afacd9a9@googlegroups.com> <CAPTjJmqTnwJq_gSu6cUZZ4P3ifqGj0Q_0koqwhPz6gibq_SR2g@mail.gmail.com> <mailman.67.1468816557.2307.python-list@python.org> <4a5bcb6a-6fc9-4c60-a24c-0c2dc3ffcb19@googlegroups.com> <CAPTjJmq03aA5UaT0+EqGLZeZ8yk=qm5ZTnqCgmE539BRc5TVYQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <4a5bcb6a-6fc9-4c60-a24c-0c2dc3ffcb19@googlegroups.com>
Precedence: list
Xref: csiph.com comp.lang.python:111593

On Mon, Jul 18, 2016 at 3:37 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Monday, July 18, 2016 at 10:06:11 AM UTC+5:30, Chris Angelico wrote:
>> Why does that mean that 3.0 is inexact? In what way is 3.0 "inexact"?
>> It's an exact value representing the integer three.
>
> [Assuming you are asking in good faith and in the same vein I am answerin=
g
> without claiming to know all this with much certainty]

[Yes, I was]

> I believe we need to distinguish between the intention and its realizatio=
n
> within the syntactic (in this case lexical) structures of the language.
>
> The INTENTION is that in addition to capturing the usual number tower
> =E2=84=95 =E2=8A=82 =E2=84=A4 =E2=8A=82 =E2=84=9D (or parts therefore)
> scheme also captures ORTHOGONALLY (word in the docs) the (in)exactness at=
tribute
>
> In the realization, the designers need to (over)load these different attr=
ibutes
> onto numeric constants.
> So the ruse chosen is that fraction-constants by default are exact
> Decimal constants are inexact
> And one can override any of these by suitable a function
> [At least that's my understanding]

Ah. Okay. So in theory, you could have exact float literals and
inexact integer literals, if you tag them in some way:

300   ; Exactly 300
300!  ; Inexact - roughly 300
3.0  ; Exactly three
3.0!  ; Roughly three and zero tenths

This then eliminates the problem of representing exact non-integers
(for instance, IEEE floating point has no problem representing exactly
3.125, but if all floats are automatically "inexact", you lose that
facility), but it then pushes the question of "what does inexact
really MEAN" up to the programmer, at which point it really ends up in
the domain of error values rather than a simple flag "inexact". In
Python, this sort of thing would be perfect as a PyPI package -
"numbers with error values" - which could then define all arithmetic
operations and how they combine error values (with an implicit upcast
from any numeric type to "number with error value of +/- 0"). It
wouldn't need to be part of the core language.

ChrisA