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
In article , Roy Smith wrote: > In article , > Chris Angelico wrote: > > > On Mon, Jun 16, 2014 at 11:57 AM, Roy Smith wrote: > > > In article , > > > Chris Angelico 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
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 , Chris Angelico wrote: > On Mon, Jun 16, 2014 at 11:57 AM, Roy Smith wrote: > > In article , > > Chris Angelico 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 Mon, Jun 16, 2014 at 11:57 AM, Roy Smith wrote: > In article , > Chris Angelico 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 , Chris Angelico 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 10:38 AM, Steven D'Aprano 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 "", line 1, in 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 "", line 1, in 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
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 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 >> > 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 Sun, Jun 15, 2014 at 11:28 AM, Roy Smith wrote: > In article <539dbcbe$0$29988$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano 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 >> > 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 "", line 1, in 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
In article <539dbcbe$0$29988$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano 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 > > 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, 15 Jun 2014 01:22:50 -0600, Ian Kelly wrote: > On Sat, Jun 14, 2014 at 8:51 PM, Steven D'Aprano > 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
On Sat, Jun 14, 2014 at 8:51 PM, Steven D'Aprano 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