# Python's numeric tower

S

#### Steven D'Aprano

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)?

I

#### Ian Kelly

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)?
False

S

#### Steven D'Aprano

Well, that surprises and disappoints me, but thank you for the answer.

R

#### Roy Smith

Steven D'Aprano said:
Well, that surprises and disappoints me, but thank you for the answer.

Why would you expect Decimal to be a subclass of Complex?

I

#### Ian Kelly

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:
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.

S

#### Steven D'Aprano

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.

C

#### Chris Angelico

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:
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'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:
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

R

#### Roy Smith

Chris Angelico said:
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!

C

#### Chris Angelico

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

R

#### Roy Smith

Chris Angelico said:
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().

R

#### Roy Smith

Roy Smith said:
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().

M

#### Mark Lawrence

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?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

### Members online

No members online now.