Re: Python's numeric tower
On 16/06/2014 04:38, Dan Sommers wrote: On Sun, 15 Jun 2014 22:17:57 -0400, Roy Smith wrote: I don't believe HandGrenade implements throw(). It does, however, implement lobbeth(). And therein lies the problem with Object Oriented Programming: instances of HandGrenade neither throw nor lobbeth. One, Two, Five'ly yours, Dan The above looks like a bug that should have been picked up, why hasn't OverflowError been raised? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's numeric tower
On Sat, Jun 14, 2014 at 8:51 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Does anyone know any examples of values or types from the standard library or well-known third-party libraries which satisfies isinstance(a, numbers.Number) but not isinstance(a, numbers.Complex)? issubclass(decimal.Decimal, numbers.Number) True issubclass(decimal.Decimal, numbers.Complex) False -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's numeric tower
On Sun, 15 Jun 2014 01:22:50 -0600, Ian Kelly wrote: On Sat, Jun 14, 2014 at 8:51 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Does anyone know any examples of values or types from the standard library or well-known third-party libraries which satisfies isinstance(a, numbers.Number) but not isinstance(a, numbers.Complex)? issubclass(decimal.Decimal, numbers.Number) True issubclass(decimal.Decimal, numbers.Complex) False Well, that surprises and disappoints me, but thank you for the answer. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's numeric tower
In article 539dbcbe$0$29988$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sun, 15 Jun 2014 01:22:50 -0600, Ian Kelly wrote: On Sat, Jun 14, 2014 at 8:51 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Does anyone know any examples of values or types from the standard library or well-known third-party libraries which satisfies isinstance(a, numbers.Number) but not isinstance(a, numbers.Complex)? issubclass(decimal.Decimal, numbers.Number) True issubclass(decimal.Decimal, numbers.Complex) False Well, that surprises and disappoints me, but thank you for the answer. Why would you expect Decimal to be a subclass of Complex? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's numeric tower
On Sun, Jun 15, 2014 at 11:28 AM, Roy Smith r...@panix.com wrote: In article 539dbcbe$0$29988$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sun, 15 Jun 2014 01:22:50 -0600, Ian Kelly wrote: On Sat, Jun 14, 2014 at 8:51 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Does anyone know any examples of values or types from the standard library or well-known third-party libraries which satisfies isinstance(a, numbers.Number) but not isinstance(a, numbers.Complex)? issubclass(decimal.Decimal, numbers.Number) True issubclass(decimal.Decimal, numbers.Complex) False Well, that surprises and disappoints me, but thank you for the answer. Why would you expect Decimal to be a subclass of Complex? One might expect it for the same reason that float is a subclass of Complex. Decimal was intentionally excluded from the numeric tower (as noted in PEP 3141), but apparently it still subclasses Number. As I understand it the reason Decimal was excluded was because it doesn't fully implement the methods of Complex; for example, given two Complex instances, one expects to be able to add them, but that doesn't always hold for Decimal depending on the type of the other operand: Decimal(2.0) + 2.0 Traceback (most recent call last): File stdin, line 1, in module TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float' The Number ast doesn't specify any particular behavior and is there to to make it easy for people to be fuzzy about what kind of number they expect, so I guess the developers so no harm in letting Decimal subclass it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's numeric tower
On Sun, 15 Jun 2014 13:28:44 -0400, Roy Smith wrote:
In article 539dbcbe$0$29988$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Sun, 15 Jun 2014 01:22:50 -0600, Ian Kelly wrote:
On Sat, Jun 14, 2014 at 8:51 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Does anyone know any examples of values or types from the standard
library or well-known third-party libraries which satisfies
isinstance(a, numbers.Number) but not isinstance(a,
numbers.Complex)?
issubclass(decimal.Decimal, numbers.Number)
True
issubclass(decimal.Decimal, numbers.Complex)
False
Well, that surprises and disappoints me, but thank you for the answer.
Why would you expect Decimal to be a subclass of Complex?
py from decimal import Decimal
py Decimal(1.5).imag
Decimal('0')
Mathematically, ℂ (complex) is a superset of ℝ (real), and Decimals are a
kind of real(ish) number, like float:
py from numbers import Complex
py isinstance(1.5, Complex)
True
But then I suppose it is understandable that Decimal doesn't support the
full range of complex arithmetic.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python's numeric tower
On Mon, Jun 16, 2014 at 10:38 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Mathematically, ℂ (complex) is a superset of ℝ (real), and Decimals are a
kind of real(ish) number, like float:
The Python complex type represents a subset of ℂ. The Python Decimal
and float types implement a subset of ℝ, which as you say is a subset
of ℂ. The Python int type implements a subset of ℤ. (Although if you
have infinite storage, you could theoretically represent all of ℤ with
int, and possibly all of ℝ with Decimal. But I don't know of any
Python implementation that can utilize infinite RAM.)
The question isn't really about the mathematical number sets, but
about what operations you can do. The numbers.Complex type specifies
(3.4.0):
class Complex(Number)
| Complex defines the operations that work on the builtin complex type.
|
| In short, those are: a conversion to complex, .real, .imag, +, -,
| *, /, abs(), .conjugate, ==, and !=.
From what I can see, all of those operations are defined for Decimal,
*as long as you work exclusively with Decimal*. You can check their
.real and .imag (.imag will be Decimal('0'), and .real is self), you
can conjugate them (returns self), and you can do arithmetic with
them. But you can't mix complex and decimal, any more than you can mix
float and decimal:
Decimal('2')+3.0
Traceback (most recent call last):
File pyshell#30, line 1, in module
Decimal('2')+3.0
TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'
Decimal('2')+complex(3.0)
Traceback (most recent call last):
File pyshell#31, line 1, in module
Decimal('2')+complex(3.0)
TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'complex'
Ergo, currently, you can't say that decimal.Decimal can be treated as
a complex. (Although you can call complex(d) and get back a meaningful
value, within the limits of precision - again, same as with float(d).)
To contrast, numbers.Number places very few requirements on its
subclasses. And decimal.Decimal isn't a subclass of any of the rest of
the tower:
for cls in numbers.__all__:
print(cls,-,isinstance(d,getattr(numbers,cls)))
Number - True
Complex - False
Real - False
Rational - False
Integral - False
As I understand it, isinstance(x,numbers.Complex) should be True for
anything that you can treat like a complex() - that is, that you can
add it to a complex(), do operations on it, etc, etc, etc. I'm not
sure what isinstance(x,numbers.Number) promises in terms of usability;
I guess if you have a list of Numbers that are all the same type, you
can probably sum them, but you can sum non-Numbers too. The docstring
is a bit vague - sure, it's a number, but what can you do with it?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python's numeric tower
In article mailman.11074.1402880950.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: I guess if you have a list of Numbers that are all the same type, you can probably sum them, but you can sum non-Numbers too. The docstring is a bit vague - sure, it's a number, but what can you do with it? You can use it to count to three! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's numeric tower
On Mon, Jun 16, 2014 at 11:57 AM, Roy Smith r...@panix.com wrote:
In article mailman.11074.1402880950.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
I guess if you have a list of Numbers that are all the same type, you
can probably sum them, but you can sum non-Numbers too. The docstring
is a bit vague - sure, it's a number, but what can you do with it?
You can use it to count to three!
Since increment is not a provided method, and the + and += operators
are not guaranteed to be defined for any definition of 1 on the other
side, I'm not sure that's actually true... but if you hold a hand
grenade and want to know whether to count to Decimal('3') or 3+0j or
Fraction(3, 1), I'm just going to tell you to throw the thing already!
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python's numeric tower
In article mailman.11075.1402884256.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Mon, Jun 16, 2014 at 11:57 AM, Roy Smith r...@panix.com wrote:
In article mailman.11074.1402880950.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
I guess if you have a list of Numbers that are all the same type, you
can probably sum them, but you can sum non-Numbers too. The docstring
is a bit vague - sure, it's a number, but what can you do with it?
You can use it to count to three!
Since increment is not a provided method, and the + and += operators
are not guaranteed to be defined for any definition of 1 on the other
side, I'm not sure that's actually true... but if you hold a hand
grenade and want to know whether to count to Decimal('3') or 3+0j or
Fraction(3, 1), I'm just going to tell you to throw the thing already!
ChrisA
I don't believe HandGrenade implements throw(). It does, however,
implement lobbeth().
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python's numeric tower
On Sun, 15 Jun 2014 22:17:57 -0400, Roy Smith wrote: I don't believe HandGrenade implements throw(). It does, however, implement lobbeth(). And therein lies the problem with Object Oriented Programming: instances of HandGrenade neither throw nor lobbeth. One, Two, Five'ly yours, Dan -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's numeric tower
In article roy-ed231f.22175715062...@news.panix.com,
Roy Smith r...@panix.com wrote:
In article mailman.11075.1402884256.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Mon, Jun 16, 2014 at 11:57 AM, Roy Smith r...@panix.com wrote:
In article mailman.11074.1402880950.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
I guess if you have a list of Numbers that are all the same type, you
can probably sum them, but you can sum non-Numbers too. The docstring
is a bit vague - sure, it's a number, but what can you do with it?
You can use it to count to three!
Since increment is not a provided method, and the + and += operators
are not guaranteed to be defined for any definition of 1 on the other
side, I'm not sure that's actually true... but if you hold a hand
grenade and want to know whether to count to Decimal('3') or 3+0j or
Fraction(3, 1), I'm just going to tell you to throw the thing already!
ChrisA
I don't believe HandGrenade implements throw(). It does, however,
implement lobbeth().
On second thought, it probably implements lob(). You can, however
derive lobbeth() by calling conjugate().
--
https://mail.python.org/mailman/listinfo/python-list
