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 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

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

Gene Heskett wrote:
> The theory of relativity says that the faster you 
> are going, the more massive you become.

It doesn't, really. The equations only seem to say that
if you insist on keeping the Newtonian definitions of
momentum and kinetic energy in the context of relativity,
which is a silly thing to do when you think about it.
Physicists realised that nearly a century ago, and no
longer use the idea of a velocity-dependent mass.

-- 
Greg

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

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

Gregory Ewing <greg.ewing@canterbury.ac.nz>:
> Physicists realised that nearly a century ago, and no
> longer use the idea of a velocity-dependent mass.

   Roche states that about 60% of modern authors just use rest mass and
   avoid relativistic mass.

   <URL:
   https://en.wikipedia.org/wiki/Mass_in_special_relativity#Controversy>


Marko

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

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

On Tue, 19 Jul 2016 01:25 am, Ian Kelly wrote:

> On Mon, Jul 18, 2016 at 3:29 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Monday 18 July 2016 14:16, Rustom Mody wrote:
>>> 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,
>> π).
> 
> Off-topic, c being a fundamental constant is actually in the latter
> category. Its *exact* value is 299792458 m/s.
> 
> The length of the meter, on the other hand, is defined as the distance
> traveled by light in a vacuum in 1/299792458 seconds and is subject to
> the precision of measurements.

You're right, of course, but that's a post-facto redefinition of both c and
the metre. Historically, the metre was defined first, then people spent a
lot of time measuring the speed of light (I believe it was Galileo who made
the first known attempt). Eventually, physicists decided that it was easier
to declare by fiat that c = 299792458 m/s EXACTLY, and use that definition
to imply a standard metre, rather than keep a standard metre and use that
to measure c.

That makes it a matter of convenience and practicality rather than purity.
It also reflects the current theoretical paradigm that sees c as a constant
and both distance and time subject to distortion. Had special and general
relativity been disproven, or never invented, it's unlikely that we would
have declared c to be more fundamental than distance.

(We haven't declared that G is exactly such-and-such a value, and used that
to define the kilogram.)



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

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

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

On Mon, Jul 18, 2016, at 00:46, Ben Finney wrote:
> 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.

There's no reason it shouldn't be a property of an object of a numeric
type available in a programming environment though.

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

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

On Mon, 18 Jul 2016 11:25 pm, Random832 wrote:

> On Mon, Jul 18, 2016, at 00:46, Ben Finney wrote:
>> 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.
> 
> There's no reason it shouldn't be a property of an object of a numeric
> type available in a programming environment though.

Yes, there is a reason.

Objects of numeric types in programming environments are intended to model
numbers. Since numbers are not "exact" or "inexact" (but only
calculations), then adding an "exact" attribute to the number makes as much
sense as adding attributes "colour", "weight", or "flavour".



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

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

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

Random832 <random832@fastmail.com> writes:

> On Mon, Jul 18, 2016, at 00:46, Ben Finney wrote:
> > 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.
>
> There's no reason it shouldn't be a property of an object of a numeric
> type available in a programming environment though.

Yes. Because the object is not a number, it is a representation of a
number :-)

-- 
 \       “Truth is stranger than fiction, but it is because fiction is |
  `\     obliged to stick to possibilities, truth isn't.” —Mark Twain, |
_o__)                                          _Following the Equator_ |
Ben Finney

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

#111498

On Sat, Jul 16, 2016 at 4:53 PM, Random832 <random832@fastmail.com> wrote:
> On Sat, Jul 16, 2016, at 02:29, Chris Angelico wrote:
>> The difference between ints and floats can lead to bugs, too. Which
>> one should we eliminate?
>
> Eliminate both of them. Move to a single abstract numeric type* a la
> Scheme, with an "inexact" attribute (inexact numbers may or may not be
> represented by a float, or by the same bigint/decimal/rational types as
> exact ones with a flag set to mark them as inexact.)
>
> *which may have multiple concrete representations, just as our single
> abstract unicode string type has different concrete representations for
> ASCII, Latin-1, UCS-2, and UCS-4.

Thing is, a Unicode string could be represented in exactly one way
(UCS-4), with identical semantics. Look at Py2's "wide build" (eg most
Linux builds). The rest is just optimization. With a single abstract
numeric type, what exactly does "inexact" mean, where does it come
from, and how does that affect the expected behaviour and performance
of numbers? Will an "Exact" non-integer be stored as Decimal or
Fraction? How do you know? They have vastly different semantics, and
you should be able to choose.

ChrisA

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

#111499

Chris Angelico <rosuav@gmail.com>:
> With a single abstract numeric type, what exactly does "inexact" mean,
> where does it come from, and how does that affect the expected
> behaviour and performance of numbers?

Not much is said in the standard:

   Thus inexactness is a contagious property of a number. If two
   implementations produce exact results for a computation that did not
   involve inexact intermediate results, the two ultimate results will
   be mathematically equivalent. This is generally not true of
   computations involving inexact numbers since approximate methods such
   as floating point arithmetic may be used, but it is the duty of each
   implementation to make the result as close as practical to the
   mathematically ideal result.

   <URL: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.h
   tml#%_sec_6.2.2>

Exactness should be considered a flag that expresses whether the result
is an approximation.

> Will an "Exact" non-integer be stored as Decimal or Fraction? How do
> you know? They have vastly different semantics, and you should be able
> to choose.

The manual of the Scheme implementation would likely explain the
particular properties of its number system implementation. At its
simplest, you could have an implementation that only supports, say,
signed 16-bit exact integers. All other numbers would be inexact floats.

   Implementations are encouraged, but not required, to support exact
   integers and exact rationals of practically unlimited size and
   precision, and to implement the above procedures and the / procedure
   in such a way that they always return exact results when given exact
   arguments. If one of these procedures is unable to deliver an exact
   result when given exact arguments, then it may either report a
   violation of an implementation restriction or it may silently coerce
   its result to an inexact number. Such a coercion may cause an error
   later.

   An implementation may use floating point and other approximate
   representation strategies for inexact numbers. This report
   recommends, but does not require, that the IEEE 32-bit and 64-bit
   floating point standards be followed by implementations that use
   flonum representations, and that implementations using other
   representations should match or exceed the precision achievable using
   these floating point standards [12].

   In particular, implementations that use flonum representations must
   follow these rules: A flonum result must be represented with at least
   as much precision as is used to express any of the inexact arguments
   to that operation. It is desirable (but not required) for potentially
   inexact operations such as sqrt, when applied to exact arguments, to
   produce exact answers whenever possible (for example the square root
   of an exact 4 ought to be an exact 2).

   <URL: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.h
   tml#%_sec_6.2.3>


Marko

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

#111519

On Sat, Jul 16, 2016, at 03:27, Chris Angelico wrote:
> Will an "Exact" non-integer be stored as Decimal or
> Fraction? How do you know? They have vastly different semantics, and
> you should be able to choose.

Er, the point is for them to _not_ have different semantics. A decimal
storage format would simply be an optimization for a fraction whose
denominator is a power of 10 (or of 2 and 5)

The semantics of the current Decimal class are those of an inexact
number.

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

#111520

Random832 <random832@fastmail.com>:

> On Sat, Jul 16, 2016, at 03:27, Chris Angelico wrote:
>> Will an "Exact" non-integer be stored as Decimal or
>> Fraction? How do you know? They have vastly different semantics, and
>> you should be able to choose.
>
> Er, the point is for them to _not_ have different semantics. A decimal
> storage format would simply be an optimization for a fraction whose
> denominator is a power of 10 (or of 2 and 5)
>
> The semantics of the current Decimal class are those of an inexact
> number.

The most common use for Python's Decimal class is *exact* amounts of
currency.

The exactness of a number in Scheme is just a flag. You can force
exactness of a number literal with the #e or #i prefix:

   (exact? #e1.2e-7)
   ==> #t                  # 1.2e-7 exactly
   (exact? #i7)
   ==> #f                  # approximately 7


Marko

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

#111522

On Sun, Jul 17, 2016 at 4:04 AM, Random832 <random832@fastmail.com> wrote:
> On Sat, Jul 16, 2016, at 03:27, Chris Angelico wrote:
>> Will an "Exact" non-integer be stored as Decimal or
>> Fraction? How do you know? They have vastly different semantics, and
>> you should be able to choose.
>
> Er, the point is for them to _not_ have different semantics. A decimal
> storage format would simply be an optimization for a fraction whose
> denominator is a power of 10 (or of 2 and 5)
>
> The semantics of the current Decimal class are those of an inexact
> number.

In that case, an 'Exact' non-integer will have appalling performance -
fractions.Fraction doesn't really work all that nicely when the
numbers start getting huge.

ChrisA

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

#111523

Chris Angelico <rosuav@gmail.com>:

> In that case, an 'Exact' non-integer will have appalling performance -
> fractions.Fraction doesn't really work all that nicely when the
> numbers start getting huge.

In Scheme, any math operation is allowed to drop exactness:

   If one of these procedures is unable to deliver an exact result when
   given exact arguments, then it may either report a violation of an
   implementation restriction or it may silently coerce its result to an
   inexact number.

   <URL: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5r
   s-Z-H-9.html#%_sec_6.2.3>


Now, that's neither the recommendation nor the reality; exactness is
preserved at the expense of efficiency. However, that's unlikely to be
an issue in the normal use of Python's Decimal.


Marko

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

#111525

On Sun, Jul 17, 2016 at 7:27 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> In that case, an 'Exact' non-integer will have appalling performance -
>> fractions.Fraction doesn't really work all that nicely when the
>> numbers start getting huge.
>
> In Scheme, any math operation is allowed to drop exactness:
>
>    If one of these procedures is unable to deliver an exact result when
>    given exact arguments, then it may either report a violation of an
>    implementation restriction or it may silently coerce its result to an
>    inexact number.

The trouble is, repeated addition of fractions is *able* to deliver an
exact result. It just might result in an incredibly slow program. And
then if you mix types, does it aim for the greatest possible
'accuracy', even if that's not quite accurate? (For instance, if you
add 0.2 to 5/8, does it convert to float or to fraction?)

ChrisA

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

#111554

Chris Angelico <rosuav@gmail.com>:

> The trouble is, repeated addition of fractions is *able* to deliver an
> exact result. It just might result in an incredibly slow program.

True, although the programmer has control over the feature. If you
*want* the luxury of exact fractions, you pay the price. If you don't,
you make the numbers inexact.

A somewhat analogous situation is there in Python's integers, which have
an unlimited range. The feature is extremely useful in cryptography, for
example (DSA verification is a couple of lines of Python).

> And then if you mix types, does it aim for the greatest possible
> 'accuracy', even if that's not quite accurate? (For instance, if you
> add 0.2 to 5/8, does it convert to float or to fraction?)

   Thus inexactness is a contagious property of a number.

   <URL: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5r
   s-Z-H-9.html#%_sec_6.2.3>

Guile:

   (+ 0.2 5/8)
   ==> 0.825
   (exact? (+ 0.2 5/8))
   ==> #f

Python, for comparison:

   >>> 0.2 + fractions.Fraction(5, 8)
   0.825
   >>> decimal.Decimal("0.1") + 0.1
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and
    'float'
   >>> fractions.Fraction(5, 8) + decimal.Decimal("0.1")
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: unsupported operand type(s) for +: 'Fraction' and 'decim
   al.Decimal'


Marko

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

#111556

On Sun, Jul 17, 2016 at 5:41 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> The trouble is, repeated addition of fractions is *able* to deliver an
>> exact result. It just might result in an incredibly slow program.
>
> True, although the programmer has control over the feature. If you
> *want* the luxury of exact fractions, you pay the price. If you don't,
> you make the numbers inexact.

Not if you have a single "Number" type:

On Sat, Jul 16, 2016 at 4:53 PM, Random832 <random832@fastmail.com> wrote:
> Eliminate both of them. Move to a single abstract numeric type* a la
> Scheme, with an "inexact" attribute (inexact numbers may or may not be
> represented by a float, or by the same bigint/decimal/rational types as
> exact ones with a flag set to mark them as inexact.)

Currently yes, you can choose to use fractions.Fraction and pay the
price. How, if you have a single type with different representations,
can you make that choice?

ChrisA

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

#111557

On Sun, Jul 17, 2016, at 03:51, Chris Angelico wrote:
> > True, although the programmer has control over the feature. If you
> > *want* the luxury of exact fractions, you pay the price. If you don't,
> > you make the numbers inexact.
> 
> Not if you have a single "Number" type:

Saying that exact and inexact numbers can't be a single type is like
saying positive and negative numbers can't be the same type.

Saying that fractions and floats can't be a single type is like saying
ASCII strings and UCS-4 strings can't be the same type within the FSR.
"Single abstract Number type" doesn't preclude a "FNR" where some Number
objects are represented as floats and others are not.

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

#111565

On Sun, 17 Jul 2016 06:03 pm, Random832 wrote:

> On Sun, Jul 17, 2016, at 03:51, Chris Angelico wrote:
>> > True, although the programmer has control over the feature. If you
>> > *want* the luxury of exact fractions, you pay the price. If you don't,
>> > you make the numbers inexact.
>> 
>> Not if you have a single "Number" type:
> 
> Saying that exact and inexact numbers can't be a single type is like
> saying positive and negative numbers can't be the same type.

Unless you're talking about about interval arithmetic, "inexact number" is
an oxymoron. Numbers are not inexact or exact, only calculations are.
0.09090909090909091 is just as exact as Fraction(1, 11), they just happen
to be different numbers. The first is exactly:

Fraction(3275345183542179, 36028797018963968)

which is a perfectly good and exact number, precisely equal to:

Fraction(3275345183542178, 36028797018963968) + 
    Fraction(1, 36028797018963968)

among many other exact calculations. So I would like to know how you justify
claiming that one number is exact and the other is not?




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

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

#111558

On Sun, Jul 17, 2016, at 03:51, Chris Angelico wrote:
> Currently yes, you can choose to use fractions.Fraction and pay the
> price. How, if you have a single type with different representations,
> can you make that choice?

Sorry, I forgot to answer your question. Though, your implicit claim
that it's impossible to make choices if your choices aren't represented
by different types is absurd.

For example, you could have a function that returns an inexact number
with the (approximately) same value as the given number.

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

#111559

On Sun, Jul 17, 2016 at 6:08 PM, Random832 <random832@fastmail.com> wrote:
> On Sun, Jul 17, 2016, at 03:51, Chris Angelico wrote:
>> Currently yes, you can choose to use fractions.Fraction and pay the
>> price. How, if you have a single type with different representations,
>> can you make that choice?
>
> Sorry, I forgot to answer your question. Though, your implicit claim
> that it's impossible to make choices if your choices aren't represented
> by different types is absurd.
>
> For example, you could have a function that returns an inexact number
> with the (approximately) same value as the given number.

Which inexact type, though? Do you get decimal.Decimal, float, or
something else? How do you make that choice? And it's a critical
choice to make. They're not just "inexact numbers". You can have an
exact float (eg 7/2) or an inexact one, and same with Decimal.

ChrisA

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

#111422

On Wed, Jul 13, 2016 at 5:54 PM, Peter Otten <__peter__@web.de> wrote:
> Lawrence D’Oliveiro wrote:
>
>> On Friday, July 8, 2016 at 7:38:56 PM UTC+12, Peter Otten wrote:
>>
>>> There is a test
>>>
>>> if not object:
>>>     raise ImportError('no Python documentation found for %r' % thing)
>>>
>>> in the pydoc module. So all you need is to ensure that your Registry
>>> evaluates to True in a boolean context, e. g. by putting something into
>>> it:
>>
>> And there are still those who think that Python’s lax acceptance of
>> non-boolean values as booleans is a good idea...
>
> I don't think this particular problem serves as an argument for stricter
> handling of boolean expressions because the fix
>
> if object is not None: ...
>
> is not completely correct, either:

A better fix would be to have the locate function raise an exception
if the thing is not found instead of returning None.

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

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

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

csiph-web