Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #111197 > unrolled thread

Clean Singleton Docstrings

Back to article view | Back to comp.lang.python

Contents

  Clean Singleton Docstrings Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-07 23:46 +0000
    Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-08 12:53 +1000
    Re: Clean Singleton Docstrings Michael Selik <michael.selik@gmail.com> - 2016-07-07 23:43 -0400
      Re: Clean Singleton Docstrings Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-08 16:57 +0000
        Re: Clean Singleton Docstrings Ethan Furman <ethan@stoneleaf.us> - 2016-07-08 13:00 -0700
    Re: Clean Singleton Docstrings Peter Otten <__peter__@web.de> - 2016-07-08 09:38 +0200
      Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-08 19:20 +1000
        Re: Clean Singleton Docstrings Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-08 16:47 +0000
      Re: Clean Singleton Docstrings Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-13 15:42 -0700
        Re: Clean Singleton Docstrings Peter Otten <__peter__@web.de> - 2016-07-14 01:54 +0200
          Re: Clean Singleton Docstrings Rustom Mody <rustompmody@gmail.com> - 2016-07-15 21:04 -0700
            Re: Clean Singleton Docstrings Ethan Furman <ethan@stoneleaf.us> - 2016-07-15 21:20 -0700
              Re: Clean Singleton Docstrings Rustom Mody <rustompmody@gmail.com> - 2016-07-15 22:51 -0700
              Re: Clean Singleton Docstrings Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-15 23:19 -0700
                Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-16 16:29 +1000
                Re: Clean Singleton Docstrings Random832 <random832@fastmail.com> - 2016-07-16 02:53 -0400
                  Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-16 18:54 +1000
                  Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-16 19:46 +1000
                    What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-17 21:16 -0700
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-18 14:35 +1000
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-17 22:37 -0700
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-18 15:48 +1000
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 09:21 +0300
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Random832 <random832@fastmail.com> - 2016-07-18 09:32 -0400
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Ben Finney <ben+python@benfinney.id.au> - 2016-07-18 14:46 +1000
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-17 22:22 -0700
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-18 19:29 +1000
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 13:00 +0300
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-18 20:15 +1000
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 03:24 -0700
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-18 20:37 +1000
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 14:38 +0300
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Peter Otten <__peter__@web.de> - 2016-07-18 14:58 +0200
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-19 13:42 +1000
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 21:58 -0700
                                Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-19 15:30 +1000
                                Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-20 15:42 +1000
                                  Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Angelico <rosuav@gmail.com> - 2016-07-20 16:11 +1000
                                  Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-20 09:09 +0200
                                    Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 10:25 +0300
                                    Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Steven D'Aprano <steve@pearwood.info> - 2016-07-20 22:47 +1000
                                      Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 16:54 +0300
                                        Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Angelico <rosuav@gmail.com> - 2016-07-21 00:26 +1000
                                          Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 17:59 +0300
                                            Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Rustom Mody <rustompmody@gmail.com> - 2016-07-20 22:38 -0700
                                              Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-21 10:52 +0300
                                                Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Angelico <rosuav@gmail.com> - 2016-07-21 18:46 +1000
                                                  Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-21 12:09 +0300
                                      Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-22 00:54 +0100
                                        Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Kaynor <ckaynor@zindagigames.com> - 2016-07-21 17:43 -0700
                                          Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-22 17:14 +0100
                                  Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Rustom Mody <rustompmody@gmail.com> - 2016-07-20 22:28 -0700
                                    Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Angelico <rosuav@gmail.com> - 2016-07-21 15:35 +1000
                                      Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Rustom Mody <rustompmody@gmail.com> - 2016-07-20 22:52 -0700
                                    Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-21 16:34 +1000
                                      Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Rustom Mody <rustompmody@gmail.com> - 2016-07-21 06:14 -0700
                                        Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Steven D'Aprano <steve@pearwood.info> - 2016-07-22 02:10 +1000
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-19 15:27 +1000
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 03:14 -0700
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-18 09:25 -0600
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 18:40 +0300
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 18:55 +0300
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-18 11:13 -0600
                                Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 21:58 +0300
                                  Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 17:36 -0700
                                    Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-19 13:16 +1000
                                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 20:26 -0700
                                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Gene Heskett <gheskett@shentel.net> - 2016-07-19 01:22 -0400
                                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-19 10:46 -0700
                                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Gene Heskett <gheskett@shentel.net> - 2016-07-19 16:35 -0400
                                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 01:17 +0300
                                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Random832 <random832@fastmail.com> - 2016-07-19 23:15 -0400
                                                Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 10:16 +0300
                                                  Re: What exactly is "exact" (was Clean Singleton Docstrings) Random832 <random832@fastmail.com> - 2016-07-20 10:00 -0400
                                                    Re: What exactly is "exact" (was Clean Singleton Docstrings) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-21 10:46 +1200
                                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-19 16:27 -0600
                                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 02:09 +0300
                                              Re: What exactly is "exact" (was Clean Singleton Docstrings) alister <alister.ware@ntlworld.com> - 2016-07-20 13:24 +0000
                                                Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-21 14:04 +1000
                                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-19 17:01 -0700
                                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-20 11:07 +1200
                                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 02:20 +0300
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-19 13:03 +1000
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Random832 <random832@fastmail.com> - 2016-07-18 09:25 -0400
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-19 13:21 +1000
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Ben Finney <ben+python@benfinney.id.au> - 2016-07-19 10:21 +1000
                Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-16 17:27 +1000
                  Re: Clean Singleton Docstrings Marko Rauhamaa <marko@pacujo.net> - 2016-07-16 10:58 +0300
                Re: Clean Singleton Docstrings Random832 <random832@fastmail.com> - 2016-07-16 14:04 -0400
                  Re: Clean Singleton Docstrings Marko Rauhamaa <marko@pacujo.net> - 2016-07-16 21:43 +0300
                Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-17 07:02 +1000
                  Re: Clean Singleton Docstrings Marko Rauhamaa <marko@pacujo.net> - 2016-07-17 00:27 +0300
                    Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-17 08:18 +1000
                      Re: Clean Singleton Docstrings Marko Rauhamaa <marko@pacujo.net> - 2016-07-17 10:41 +0300
                        Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-17 17:51 +1000
                        Re: Clean Singleton Docstrings Random832 <random832@fastmail.com> - 2016-07-17 04:03 -0400
                          Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-17 20:35 +1000
                        Re: Clean Singleton Docstrings Random832 <random832@fastmail.com> - 2016-07-17 04:08 -0400
                        Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-17 18:44 +1000
        Re: Clean Singleton Docstrings Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-13 18:25 -0600
    Re: Clean Singleton Docstrings Peter Otten <__peter__@web.de> - 2016-07-08 09:44 +0200
      Re: Clean Singleton Docstrings Rustom Mody <rustompmody@gmail.com> - 2016-07-08 01:53 -0700
    Re: What exactly is "exact" (was Clean Singleton Docstrings) Gene Heskett <gheskett@shentel.net> - 2016-07-19 23:16 -0400

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#111592 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Monday, July 18, 2016 at 10:06:11 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Jul 18, 2016 at 2:16 PM, Rustom Mody wrote:
> > On Saturday, July 16, 2016 at 3:16:48 PM UTC+5:30, Steven D'Aprano wrote:
> > Here are the first couple of hits it gives (me) for “scheme exact number”
> >
> > | Scheme integers can be exact and inexact. For example, a number
> > | written as 3.0 with an explicit decimal-point is inexact, but it
> > | is also an integer.
> >
> > AIUI…
> > There are two almost completely unrelated notions of exact
> >
> > 1. ⅓ in decimal cannot be exactly represented though 0.3 0.33 etc are approximations.
> >    We could call these inexact forms of ⅓
> >
> > 2. Measurement and observation produces numbers.  These are inexact inherently.
> >
> > Scheme's notion of exact is towards capturing the second notion.
> 
> 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 answering
without claiming to know all this with much certainty]

I believe we need to distinguish between the intention and its realization
within the syntactic (in this case lexical) structures of the language.

The INTENTION is that in addition to capturing the usual number tower
ℕ ⊂ ℤ ⊂ ℝ (or parts therefore)
scheme also captures ORTHOGONALLY (word in the docs) the (in)exactness attribute

In the realization, the designers need to (over)load these different attributes
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]

[toc] | [prev] | [next] | [standalone]

#111593 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

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 answering
> without claiming to know all this with much certainty]

[Yes, I was]

> I believe we need to distinguish between the intention and its realization
> within the syntactic (in this case lexical) structures of the language.
>
> The INTENTION is that in addition to capturing the usual number tower
> ℕ ⊂ ℤ ⊂ ℝ (or parts therefore)
> scheme also captures ORTHOGONALLY (word in the docs) the (in)exactness attribute
>
> In the realization, the designers need to (over)load these different attributes
> 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

[toc] | [prev] | [next] | [standalone]

#111594 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

Chris Angelico <rosuav@gmail.com>:

> 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

In Scheme:

   #e300
   #i300
   #e3.0
   #i3.0

In principle, a Scheme implementation could have exact algebraic numbers
spiked with exact constants like e and π. In practice, exact numbers are
integers and rationals, while inexact numbers are floats and complex
numbers. It is a matter of opinion whether the conceptual abstraction is
worth the confusion.


Marko

[toc] | [prev] | [next] | [standalone]

#111607 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Mon, Jul 18, 2016, at 01:37, Rustom Mody wrote:
> The INTENTION is that in addition to capturing the usual number tower
> ℕ ⊂ ℤ ⊂ ℝ (or parts therefore)

Well, ℚ. You hardly ever see representations of numbers that are in ℝ-ℚ.

> scheme also captures ORTHOGONALLY (word in the docs) the (in)exactness
> attribute
>
> In the realization, the designers need to (over)load these different
> attributes 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]

The other thing you're missing is that implementations are free to
choose any representation they want (such as an IEEE binary float, or a
rational of bounded denominator) for inexact numbers, no matter how they
were written, because they're not required to preserve the exact value.
The fact that an implementation *could* also use an IEEE binary float to
represent an exact rational number whose denominator happens to be power
of two is immaterial to this discussion.

It's not required to actually be "orthogonal" in the sense that you're
imagining - i.e. being able to have inexact numbers whose machine
representations are big integers, big rationals, etc. An implementation
could choose to represent *all* inexact numbers as floats.

[toc] | [prev] | [next] | [standalone]

#111590 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

Rustom Mody <rustompmody@gmail.com> writes:

> AIUI…
> There are two almost completely unrelated notions of exact
>
> 1. ⅓ in decimal cannot be exactly represented though 0.3 0.33 etc are
> approximations. We could call these inexact forms of ⅓

Better would be to use the term already used: 0.3333 is an inexact
*representation* of ⅓.

> 2. Measurement and observation produces numbers. These are inexact
> inherently.

What is “those”? The measurement is imprecise, the observations are
inexact.

It makes no sense to say that a number is inexact. Exactness is not a
property of a number. It has one value, which is its identity; it is a
singleton.

> Scheme's notion of exact is towards capturing the second notion.
> According to which
> “There were 20,000 people in the stadium” would be an inexact integer
> [Yeah note Inexact INTEGER]

The number 20 000 is an integer. It has exactly that value.

The number of people may differ (say, 19 997 people), and “20 000
people” is then an inexact representation of the number of people.

> whereas √2, e, π are all exact.

Exactly what?

A number either is π, or it is not. The number π is not exact or
inexact; it simply has one value.

> IOW numbers picked off from the real world are just naturally wrong

The measurement can be wrong. We know that the chances are very high
that the measurement will be imprecise.

How can the *number* be wrong?

You will be able to express yourself much more clearly on this topic
when you cease conflating a number with measurements of that number, or
conflating a number with representations of that number.

-- 
 \     “I know you believe you understood what you think I said, but I |
  `\         am not sure you realize that what you heard is not what I |
_o__)                                     meant.” —Robert J. McCloskey |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#111591 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Monday, July 18, 2016 at 10:16:58 AM UTC+5:30, Ben Finney wrote:

> You will be able to express yourself much more clearly on this topic
> when you cease conflating a number with measurements of that number, or
> conflating a number with representations of that number.
> 

That more or less sums up (my understanding of) scheme's intent of having 
the exact/inexact classification: An inexact number is a measured/observed 
number with that data intentionally preserved.
An exact number is just a mathematic number ie a plain ol' number

From the scheme docs I earlier quoted: 

| [Motivation for (in)exact...]  the inexactness of a number (is a property 
| that) should not be lost silently.

As Chris question/example illustrates this may be sufficiently messed up by
floats that the distinction may not be worth making. Dunno... Ive no definite 
opinion/data on that.  To put it simply float is such a grotesquely 
unmathematical type that it is unlikely to cooperate with clean orthogonal
distinctions such as
- Exact/inexact types are orthogonal to the rest of the number hierarchy
- Modelling converts a ‘real-world’ measurement/observation into a mathematical entity
- etc

[toc] | [prev] | [next] | [standalone]

#111597 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Monday 18 July 2016 14:16, Rustom Mody wrote:

> On Saturday, July 16, 2016 at 3:16:48 PM UTC+5:30, Steven D'Aprano wrote:

>> But that's *wrong*. Numbers are never inexact. (You can have interval
>> arithmetic using "fuzzy numbers", but they're ALWAYS inexact.) It is
>> calculations which are exact or inexact, not numbers. There's no a priori
>> reason to expect that 0.499999 is "inexact" while 0.5 is "exact", you need
>> to know the calculation that generated it:
> 
> Heh! Did you check what scheme has to say about this before holding forth?
> I suggest a tool called google. It can make one seem profound

Emphasis on the "seem" rather than "actually be" *wink*


> Here are the first couple of hits it gives (me) for “scheme exact number”
[...]
> | The motivation for this behavior is that the inexactness of a number
> | should not be lost silently. 

I appreciate the motivation, but I don't think the Scheme, er, scheme is well-
thought out or meaningful. "Exact" or "inexact" is too blunt an instrument to 
be of much use. If you do a bunch of calculations, and get a result of 1.0, all 
that tells you is that the "true" (i.e. infinitely precise) value is something 
possibly centered at 1 with an unknown, not necessarily small, error.

So now you know that *at least one* calculation was inexact, but not which 
ones, or the magnitude of the errors introduced.

The Scheme system is effectively the same as a really poor interval arithmetic 
system, where numbers can be recorded in two forms:

x ± 0  # exact
x ± ∞  # inexact

and nothing in between.


> AIUI…
> There are two almost completely unrelated notions of exact
> 
> 1. ⅓ in decimal cannot be exactly represented though 0.3 0.33 etc are
> approximations.
>    We could call these inexact forms of ⅓

But 0.3 is an exact representation of 3/10, 0.1 + 0.2, 0.6/2, etc.


> 2. Measurement and observation produces numbers.  These are inexact
> inherently.
> 
> Scheme's notion of exact is towards capturing the second notion.

I don't see anything in the Guile documentation you linked to which supports 
that interpretation.


> According to which
> “There were 20,000 people in the stadium” would be an inexact integer
> [Yeah note Inexact INTEGER]

Without a bound on the error ("between 0 and 7 billion people, but probably 
20,000") that's of very little use.


> whereas
> √2, e, π are all exact.  Just that they dont have finite decimal/continued
> fraction and of course float representations.

There are computer algebra systems capable of treating irrationals like √2, e 
and π as exact numbers, but I'm pretty sure Guile is not one of them.


> In short one could think of inexact and exact — in scheme's intended
> semantics — as better called scientific (or science-ic) and mathematic
> numbers.

I don't think so. "Science" uses both experimentally-derived numbers (e.g. G, 
c, the mass of the electron) and numbers known exactly (√2, e, π).

I think one could better think of Scheme's semantics as a poorly-thought out 
hybrid between traditional numerics and a vague approximation to interval 
arithmetic.



-- 
Steve

[toc] | [prev] | [next] | [standalone]

#111598 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> I think one could better think of Scheme's semantics as a
> poorly-thought out hybrid between traditional numerics and a vague
> approximation to interval arithmetic.

Python programmers (among others) frequently run into issues with
surprising results in floating-point arithmetics. For better or worse,
Scheme has tried to abstract the concept. You don't need to explain the
ideas of IEEE 64-bit floating-point numbers or tie the hands of the
implementation. Instead, what you have is "reliable" arithmetics and
"best-effort" arithmetics, a bit like TCP is "reliable" and UDP is
"best-effort".

"Inexact" means there's a possibility of rounding errors. "Exact" means
no rounding errors were introduced by the limitations of the hardware or
the algorithms. How inexact the inexact results is a complicated topic
for numeric programming.


Marko

[toc] | [prev] | [next] | [standalone]

#111600 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Python programmers (among others) frequently run into issues with
> surprising results in floating-point arithmetics. For better or worse,
> Scheme has tried to abstract the concept. You don't need to explain the
> ideas of IEEE 64-bit floating-point numbers or tie the hands of the
> implementation. Instead, what you have is "reliable" arithmetics and
> "best-effort" arithmetics, a bit like TCP is "reliable" and UDP is
> "best-effort".

The problem with that is that failing to explain IEEE floating point
and just calling it "inexact" scares people off unnecessarily. I've
seen a lot of very intelligent people who think that you should never
compare floats with the == operator, because floats randomly introduce
"inaccuracy". And then you get these sorts of functions:

EPSILON = 0.000001 # Adjust to control numeric accuracy
def is_equal(f1, f2, epsilon=EPSILON):
    if abs(f1) > abs(f2):
        f1, f2 = f2, f1
    return abs(f2-f1) < f1*epsilon

and interminable debates about how to pick an epsilon, whether it
should be relative to the smaller value (as here) or the larger (use
f2 instead), or maybe should be an absolute value, or maybe it should
be relative to the largest/smallest value that was ever involved in
the calculation, or........

Floating point numbers are a representation of real numbers that
involves a certain amount of precision. They're ultimately no
different from grade-school arithmetic where you round stuff off so
you don't need an infinite amount of paper, except that they work with
binary rather than decimal, so people think "0.1 + 0.2 ought to be
exactly 0.3, why isn't it??", and blame floats.

Explain what they REALLY do and how they work, and you'll find they're
not so scary.

ChrisA

[toc] | [prev] | [next] | [standalone]

#111601 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Monday, July 18, 2016 at 3:45:26 PM UTC+5:30, Chris Angelico wrote:
> On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa  wrote:
> > Python programmers (among others) frequently run into issues with
> > surprising results in floating-point arithmetics. For better or worse,
> > Scheme has tried to abstract the concept. You don't need to explain the
> > ideas of IEEE 64-bit floating-point numbers or tie the hands of the
> > implementation. Instead, what you have is "reliable" arithmetics and
> > "best-effort" arithmetics, a bit like TCP is "reliable" and UDP is
> > "best-effort".
> 
> The problem with that is that failing to explain IEEE floating point
> and just calling it "inexact" scares people off unnecessarily. I've
> seen a lot of very intelligent people who think that you should never
> compare floats with the == operator, because floats randomly introduce
> "inaccuracy". And then you get these sorts of functions:
> 
> EPSILON = 0.000001 # Adjust to control numeric accuracy
> def is_equal(f1, f2, epsilon=EPSILON):
>     if abs(f1) > abs(f2):
>         f1, f2 = f2, f1
>     return abs(f2-f1) < f1*epsilon
> 
> and interminable debates about how to pick an epsilon, whether it
> should be relative to the smaller value (as here) or the larger (use
> f2 instead), or maybe should be an absolute value, or maybe it should
> be relative to the largest/smallest value that was ever involved in
> the calculation, or........
> 

I dont know what point you are trying to make
Here is behavior.  Should one use == ??

Python 2.7.11+ (default, Apr 17 2016, 14:00:29) 
[GCC 5.3.1 20160413] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> .1+.1+.1 == .3
False

EPSILON = 0.000001 # Adjust to control numeric accuracy
def is_equal(f1, f2, epsilon=EPSILON):
    if abs(f1) > abs(f2):
        f1, f2 = f2, f1
    return abs(f2-f1) < f1*epsilon 
>>> ... ... ... ... 

>>> is_equal(.1+.1+.1, .3)
True
>>> 

[toc] | [prev] | [next] | [standalone]

#111602 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Mon, Jul 18, 2016 at 8:24 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> I dont know what point you are trying to make
> Here is behavior.  Should one use == ??
>
> Python 2.7.11+ (default, Apr 17 2016, 14:00:29)
> [GCC 5.3.1 20160413] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> .1+.1+.1 == .3
> False
>
> EPSILON = 0.000001 # Adjust to control numeric accuracy
> def is_equal(f1, f2, epsilon=EPSILON):
>     if abs(f1) > abs(f2):
>         f1, f2 = f2, f1
>     return abs(f2-f1) < f1*epsilon
>>>> ... ... ... ...
>
>>>> is_equal(.1+.1+.1, .3)
> True
>>>>

Sure, simple equality hasn't given you an "intuitive" result - but
that's because your source code is in decimal. So you need to properly
understand it. If you work with something that can be represented
precisely in binary, you have no problems with equality:

>>> 7/4 + 9/4 + 11/4 + 13/4 == 10
True

It's only the repeating values that have that problem. And if you
disassemble your example, it's obvious why you get False:

>>> dis.dis(lambda: .1+.1+.1 == .3)
  1           0 LOAD_CONST               4 (0.30000000000000004)
              2 LOAD_CONST               2 (0.3)
              4 COMPARE_OP               2 (==)
              6 RETURN_VALUE

Of course those two values aren't the same. And it'd be just as
obvious if you looked at them in binary. It'd look like this in
decimal:

0.6667 + 0.6667 + 0.6667 == 2.0

Well, duh, all those intermediate values are rounded up, so you're
getting the sum of the rounding, and of course it's not equal. That's
why you need to get some comprehension of floating-point and how it
*really* functions.

ChrisA

[toc] | [prev] | [next] | [standalone]

#111603 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

Chris Angelico <rosuav@gmail.com>:
> you don't need an infinite amount of paper, except that they work with
> binary rather than decimal, so people think "0.1 + 0.2 ought to be
> exactly 0.3, why isn't it??", and blame floats.

Oh, if we only had eight fingers on our hand...

Scheme, though doesn't force the implementation to use binary. It could
use trinary or sexagesimal for all Scheme cares. The application
shouldn't care, either.


Marko

[toc] | [prev] | [next] | [standalone]

#111604 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

Marko Rauhamaa wrote:

> Chris Angelico <rosuav@gmail.com>:
>> you don't need an infinite amount of paper, except that they work with
>> binary rather than decimal, so people think "0.1 + 0.2 ought to be
>> exactly 0.3, why isn't it??", and blame floats.
> 
> Oh, if we only had eight fingers on our hand...

We already have one nibble and a carry bit, and it didn't help...

> 
> Scheme, though doesn't force the implementation to use binary. It could
> use trinary or sexagesimal for all Scheme cares. The application
> shouldn't care, either.
> 
> 
> Marko

[toc] | [prev] | [next] | [standalone]

#111626 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Mon, 18 Jul 2016 08:15 pm, Chris Angelico wrote:

> On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Python programmers (among others) frequently run into issues with
>> surprising results in floating-point arithmetics. For better or worse,
>> Scheme has tried to abstract the concept. You don't need to explain the
>> ideas of IEEE 64-bit floating-point numbers or tie the hands of the
>> implementation. Instead, what you have is "reliable" arithmetics and
>> "best-effort" arithmetics, a bit like TCP is "reliable" and UDP is
>> "best-effort".
> 
> The problem with that is that failing to explain IEEE floating point
> and just calling it "inexact" scares people off unnecessarily. I've
> seen a lot of very intelligent people who think that you should never
> compare floats with the == operator, because floats randomly introduce
> "inaccuracy". 

Yes, this. "Never compare floats for equality" is a pernicious myth that
won't die.


> And then you get these sorts of functions: 
> 
> EPSILON = 0.000001 # Adjust to control numeric accuracy
> def is_equal(f1, f2, epsilon=EPSILON):
>     if abs(f1) > abs(f2):
>         f1, f2 = f2, f1
>     return abs(f2-f1) < f1*epsilon
> 
> and interminable debates about how to pick an epsilon, whether it
> should be relative to the smaller value (as here) or the larger (use
> f2 instead), or maybe should be an absolute value, or maybe it should
> be relative to the largest/smallest value that was ever involved in
> the calculation, or........

Your code is buggy. Consider:

py> is_equal(-1.0, -1.0)
False



> Floating point numbers are a representation of real numbers that
> involves a certain amount of precision. They're ultimately no
> different from grade-school arithmetic where you round stuff off so
> you don't need an infinite amount of paper, except that they work with
> binary rather than decimal, so people think "0.1 + 0.2 ought to be
> exactly 0.3, why isn't it??", and blame floats.

Well, kinda... yes, ultimately deep down you're right. There's nothing
mysterious about floats. The lack of fundamental properties associativity:

(a+b)+c = a+(b+c)

and distributivity:

a×(b+c) = a×b + a×c

are due to numbers being recorded in finite precision, which means that some
calculations are inexact. But the *consequences* of that simple fact are
quite profound, and difficult. Earlier you mentioned "interminable debates
about how to pick an epsilon", but the reason for that is that it is
really, really hard to pick an epsilon in any systematic, objective way.

In the statistics module, I have run into this problem. Where possible, and
surprisingly often, I can test for exact equality. For example, here are a
couple of tests for geometric mean:


    def test_multiply_data_points(self):
        # Test multiplying every data point by a constant.
        c = 111
        data = [3.4, 4.5, 4.9, 6.7, 6.8, 7.2, 8.0, 8.1, 9.4]
        expected = self.func(data)*c
        result = self.func([x*c for x in data])
        self.assertEqual(result, expected)

    def test_doubled_data(self):
        # Test doubling data from [a,b...z] to [a,a,b,b...z,z].
        data = [random.uniform(1, 500) for _ in range(1000)]
        expected = self.func(data)
        actual = self.func(data*2)
        self.assertApproxEqual(actual, expected, rel=1e-13)


I didn't hand-tune the constants in test_multiply_data_points, but nor can I
guarantee that if you replace them with other constants of similar
magnitude the assertEqual test will still be appropriate.

In the test_doubled_data case, rounding errors accumulate faster, and cancel
less often, so I use an inexact comparison. Why do I check for a relative
error of 1e-13, rather than 1e-12 or 2.5e-14? *shrug* I can't give an
objective reason for it. It just seems right to me: if the relative error
was much bigger, I'd say that the geometric mean function was too
inaccurate. If it were much smaller, it's too hard for me to have the tests
pass.




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#111627 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Tuesday, July 19, 2016 at 9:12:57 AM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 18 Jul 2016 08:15 pm, Chris Angelico wrote:
> 
> > On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa wrote:
> >> Python programmers (among others) frequently run into issues with
> >> surprising results in floating-point arithmetics. For better or worse,
> >> Scheme has tried to abstract the concept. You don't need to explain the
> >> ideas of IEEE 64-bit floating-point numbers or tie the hands of the
> >> implementation. Instead, what you have is "reliable" arithmetics and
> >> "best-effort" arithmetics, a bit like TCP is "reliable" and UDP is
> >> "best-effort".
> > 
> > The problem with that is that failing to explain IEEE floating point
> > and just calling it "inexact" scares people off unnecessarily. I've
> > seen a lot of very intelligent people who think that you should never
> > compare floats with the == operator, because floats randomly introduce
> > "inaccuracy". 
> 
> Yes, this. "Never compare floats for equality" is a pernicious myth that
> won't die.

In this context, I asked Chris:
> I dont know what point you are trying to make
> Here is behavior.  Should one use == ?? 

As often happens between me and Chris I ask a ‘why’ (in this case ‘what’) question. And he gives a ‘how’ answer

So I again ask: You say «"Never compare floats for equality" is a pernicious
myth»

Given that for Chris’ is_equal we get
is_equal(.1+.1+.1, .3) is True
whereas for python builtin == its False

What (non)myth do you suggest for replacement?

[Note I am not arguing for the goodness of his is_equal]

Analogy: 
Mutable default parameters are a source of problem and confusion.

No A says. One can use them to simulate statics

No B says No problem as long as you make sure there is no mutation to the mutable, either inside or outside the function.

Sure thats all true. However
"Module-globals” is a simpler answer than A
And “DON’T” is simpler than B

So awaiting your preferred myth-ology…

[toc] | [prev] | [next] | [standalone]

#111629 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Tue, Jul 19, 2016 at 2:58 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> Analogy:
> Mutable default parameters are a source of problem and confusion.
>
> No A says. One can use them to simulate statics
>
> No B says No problem as long as you make sure there is no mutation to the mutable, either inside or outside the function.
>
> Sure thats all true. However
> "Module-globals” is a simpler answer than A
> And “DON’T” is simpler than B
>
> So awaiting your preferred myth-ology…

Preferred: Understand what's going on. Unless you're talking to a
novice/student programmer (in which case "Oh, don't do that - ask me
about it later when we're not busy fixing this problem" is a valid
response), it's best that people understand what they're working with.

ChrisA

[toc] | [prev] | [next] | [standalone]

#111657 — Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Tuesday 19 July 2016 14:58, Rustom Mody wrote:

> So I again ask: You say «"Never compare floats for equality" is a pernicious
> myth»

It is the word *never* which makes it superstition. If people said "Take care 
with using == for floats, its often not what you want" I would have no argument 
with the statement.

I'd even (reluctantly) accept "usually not what you want". But "never" is out-
and-out cargo-cult programming.


> Given that for Chris’ is_equal we get
> is_equal(.1+.1+.1, .3) is True
> whereas for python builtin == its False
> 
> What (non)myth do you suggest for replacement?

Floating point maths is hard, thinking carefully about what you are doing and 
whether it is appropriate to use == or a fuzzy almost-equal comparison, or if 
equality is the right way at all.

"But thinking is hard, can't you just tell me the answer?"

No. But I can give some guidelines:

Floating point arithmetic is deterministic, it doesn't just randomly mix in 
error out of spite or malice. So in principle, you can always estimate the 
rounding error from any calculation -- and sometimes there is none.

Arithmetic on integer-values (e.g. 1.0) is always exact, up to a limit of 
either 2**53 or approximately 1e53, I forget which. (That's why most Javascript 
programmers fail to notice that they don't have an integer type.) So long as 
you're using operations that only produce integer values from integer arguments 
(such as + - * // but not / ) then all calculations are exact. It is a waste of 
time to do:

x = 2.0
y = x*1002.0
is_equal(y, 2004.0, 1e-16)

when you can just do y == 2004.0.


If you do decide to use an absolute error, e.g.:

abs(x - y) < tolerance

keep in mind that your tolerance needs to be chosen relative to the x and y. 
For large values of x and y, the smallest possible difference may be very 
large:

py> x = 1e80
py> delta = 2**-1000
py> assert delta
py> while x + delta == x:
...     delta *= 2
... else:
...     print(delta)
... 
6.58201822928e+63


So if you're comparing two numbers around 1e80 or so, doing a "fuzzy 
comparison" using an absolute tolerance of less than 6.5e63 or so is just a 
slow and complicated way of performing an exact comparison using the == 
operator.


Absolute tolerance is faster and easier to understand, and works when the 
numbers are on opposite sides of zero, or if one (or both) is zero. But 
generally speaking, relative tolerance of one form or another:


abs(x - y) <= abs(x)*relative_tolerance
abs(x - y) <= abs(y)*relative_tolerance
abs(x - y) <= min(abs(x), abs(y))*relative_tolerance
abs(x - y) <= max(abs(x), abs(y))*relative_tolerance

is probably better, but they are slower.

A nice, simple technique is just to round:

if round(x, 6) == round(y, 6):

but that's not quite the same as abs(x-y) < 1e-6.

For library code that cares greatly about precision, using "Unit Last Place" 
(ULP) calculations are probably best. But that's a whole different story.


-- 
Steve

[toc] | [prev] | [next] | [standalone]

#111658 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Wed, Jul 20, 2016 at 3:42 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Arithmetic on integer-values (e.g. 1.0) is always exact, up to a limit of
> either 2**53 or approximately 1e53, I forget which. (That's why most Javascript
> programmers fail to notice that they don't have an integer type.)

It's 2**53, because 64-bit floats use a 53-bit mantissa (52-bits
stored and an implicit 1 at the beginning, although I can never
remember how denormals are represented). Works out to a bit under
1e16. AIUI asm.js offers a 32-bit integer type, which in fall-back
mode is represented with the native "Number" type; for values that
could be stored in a 32-bit integer, a 64-bit float is perfectly
accurate (just stupidly inefficient compared to a real integer type).

ChrisA

[toc] | [prev] | [next] | [standalone]

#111661 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

Op 20-07-16 om 07:42 schreef Steven D'Aprano:
> Floating point maths is hard, thinking carefully about what you are doing and 
> whether it is appropriate to use == or a fuzzy almost-equal comparison, or if 
> equality is the right way at all.
>
> "But thinking is hard, can't you just tell me the answer?"
>
> No. But I can give some guidelines:
>
> Floating point arithmetic is deterministic, it doesn't just randomly mix in 
> error out of spite or malice. So in principle, you can always estimate the 
> rounding error from any calculation -- and sometimes there is none.

I would like to see a practical example of such an outcome.

> Arithmetic on integer-values (e.g. 1.0) is always exact, up to a limit of 
> either 2**53 or approximately 1e53, I forget which. (That's why most Javascript 
> programmers fail to notice that they don't have an integer type.) So long as 
> you're using operations that only produce integer values from integer arguments 
> (such as + - * // but not / ) then all calculations are exact. It is a waste of 
> time to do:
>
> x = 2.0
> y = x*1002.0
> is_equal(y, 2004.0, 1e-16)
>
> when you can just do y == 2004.0.

But why perforem integer arithmetics in floats, isn't that a waste of time too?
I really see no reason to use floats if you know all your results will be integers.

-- 
Antoon.

[toc] | [prev] | [next] | [standalone]

#111664 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
> But why perforem integer arithmetics in floats,

Conceptual and practical simplificity.

> isn't that a waste of time too?

Probably not, especially compared with the overhead of boxing.


Marko

[toc] | [prev] | [next] | [standalone]

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

Back to top | Article view | comp.lang.python

csiph-web