'complex' function with string argument.

[wxjmfauth]

z = a + b*i with a, b, elements of R
z = r*exp(i*phi) with r, phi, elements of R
z = [[a, -b], [b, a]] with a, b, elements of R

This is, in my mind, more questionable:
complex(real[, imag]) -> complex number

Create a complex number from a real part and an optional imaginary part.
This is equivalent to (real + imag*1j) where imag defaults to 0.

jmf

 

[Marko Rauhamaa]

(e-mail address removed):

This is, in my mind, more questionable:

(1+1j)

I find it neat, actually.


Marko

 

[wxjmfauth]

Le mercredi 19 mars 2014 09:51:20 UTC+1, Marko Rauhamaa a écrit :

 

[Marko Rauhamaa]

(e-mail address removed):

Le mercredi 19 mars 2014 09:51:20 UTC+1, Marko Rauhamaa a écrit :
(1+3j)

So complex(a, b) is documented to produce a+bj when a and b are integers
or floats. What's more natural than saying it produces a+bj when a and b
are complex numbers? It's a straightforward generalization that in no
way violates the more limited documentation.


Marko

 

[Ian Kelly]

(e-mail address removed):


So complex(a, b) is documented to produce a+bj when a and b are integers
or floats. What's more natural than saying it produces a+bj when a and b
are complex numbers? It's a straightforward generalization that in no
way violates the more limited documentation.

When is it ever useful though? I only see a use for passing a as
complex if b is omitted, and I don't see any use for passing b as
complex. If there's no use case, then it's just a confusing edge case
that will catch unsuspecting programmers who thought the data they
were passing in was real-valued when actually it wasn't. It would be
better to raise an exception in either of the cases above, in my
opinion. If you really want to form a complex a+bj from two other
complex numbers, there is always the explicit (a + b * 1j).

That said, complex numbers have been around since 1.4 or so, and
there's probably not much chance to change it now.

 

[Marko Rauhamaa]

So complex(a, b) is documented to produce a+bj when a and b are integers
or floats. What's more natural than saying it produces a+bj when a and b
are complex numbers? It's a straightforward generalization that in no
way violates the more limited documentation.

When is it ever useful though? [...] It would be better to raise an
exception in either of the cases above, in my opinion.

I don't think it matters one way or another.

Medieval mathematicians had to address an analogous issue when they had
to decide if

x + 0

was meaningful. After all, adding nothing doesn't make any sense and
should raise a ValueError exception...


Marko

 

[Skip Montanaro]

When is it ever useful though?

About as often as int(0), float(0), or float(0.0) which all work as
expected, though probably don't turn up in a lot of code.

Skip

 

[wxjmfauth]

Le mercredi 19 mars 2014 12:04:06 UTC+1, Skip Montanaro a écrit :

About as often as int(0), float(0), or float(0.0) which all work as

expected, though probably don't turn up in a lot of code.



Skip

Your comment is equivalent to this:
0j

Both, the constructor and the docstring, are not so clean.

What to say about the __repr__ ? Are not a and b
supposed to be floats? (elements of R)
<class 'float'>

jmf

 

[Ian Kelly]

About as often as int(0), float(0), or float(0.0) which all work as
expected, though probably don't turn up in a lot of code.

The analogous call to those is complex(1+2j), which I have no problem
with, not complex(1+2j, 3+4j).

 

[Ian Kelly]

So complex(a, b) is documented to produce a+bj when a and b are integers
or floats. What's more natural than saying it produces a+bj when a and b
are complex numbers? It's a straightforward generalization that in no
way violates the more limited documentation.

When is it ever useful though? [...] It would be better to raise an
exception in either of the cases above, in my opinion.

I don't think it matters one way or another.

Medieval mathematicians had to address an analogous issue when they had
to decide if

x + 0

was meaningful. After all, adding nothing doesn't make any sense and
should raise a ValueError exception...

I wasn't aware that algebra had ValueErrors. Describing an operation
as "undefined" isn't the same thing. Anyway, if mathematicians
discover that the definitions of the past were flawed or incomplete,
then they redefine them. Case in point, if we were still using
Brahmagupta's rules for zero, then 0/0 would be 0.

Python though has backward compatibility to worry about. Because of
this, it is much simpler to add wanted behavior than to remove
unwanted behavior. If an operation can be generalized but the
generalization has no apparent use case, it *may* be better to
disallow it, with the possibility of adding it later when a user pops
up and says "Hey, this would actually be useful to me", than to allow
it from the beginning, and then have no option to remove it later when
it turns out to be merely a nuisance.

Compare for example the 2-argument int constructor. Normally this is
meant to be called like int("42", 13), where it will interpret the
digits passed as base 13 and return 54. We might generalize that and
say that if the user passes int(42, 13), it should also return 54,
seeing that the repr of 42 provides the digits "42". It is more
likely though that this call merely indicates a bug in the user's
code, and fortunately in this case what Python actually does is to
raise a TypeError.

Anyway, curious though this tangent is, further discussion is unlikely
to produce any useful outcome, so I'll just leave it there.