On Thu, Oct 10, 2013 at 11:48 AM, Neil Cerutti <ne...@norwich.edu> wrote: > On 2013-10-10, MRAB <pyt...@mrabarnett.plus.com> wrote: >> On 10/10/2013 16:57, Rotwang wrote: >>> On 10/10/2013 16:51, Neil Cerutti wrote: >>>> [...] >>>> >>>> Mixed arithmetic always promotes to the wider type (except in >>>> the case of complex numbers (Ha!)). >>>> >>>> r == c is equivalent to r == abs(c), which returns the magintude >>>> of the complex number. >>> >>> What? >>> >>> >>> -1 == -1 + 0j >>> True >>> >>> -1 == abs(-1 + 0j) >>> False >>> >>> 1 == 0 + 1j >>> False >>> >>> 1 == abs(0 + 1j) >>> True >>> >> Indeed. >> >> If r is real (float) and c is complex: >> >> r == c means r == c.real and c.imag == 0.0 > > Woah. I thought I was going by what the docs say: > > Python fully supports mixed arithmetic: when a binary > arithmetic operator has operands of different numeric types, > the operand with the “narrower” type is widened to that of the > other, where integer is narrower than floating point, which is > narrower than complex. Comparisons between numbers of mixed > type use the same rule. [2] The constructors int(), float(), > and complex() can be used to produce numbers of a specific > type. > > [...] > > [2] Not for complex numbers. Instead convert to floats using > abs() if appropriate. > > I guess the "if appropriate" part eluded my eye. When *is* it > appropriate? Apparently not during an equal test.
If you click on the footnote, it takes you to: [2]As a consequence, the list [1, 2] is considered equal to [1.0, 2.0], and similarly for tuples. The text that you have mistakenly identified as the footnote is actually part of the key to the "Notes" column of the numeric operations table, where it is referred to by the "x % y" and "divmod(x, y)" operations. Specifically, it warns of this error: >>> 3j % 2j Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can't mod complex numbers. -- https://mail.python.org/mailman/listinfo/python-list
