#13110: ComplexNumber should be able to accept the Python complex type
-------------------------------------+--------------------------------------
Reporter: eviatarbach | Owner: jason, jkantor
Type: defect | Status: needs_review
Priority: major | Milestone: sage-5.10
Component: numerical | Resolution:
Keywords: complex, beginner | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Travis Scrimshaw | Merged in:
Dependencies: | Stopgaps:
-------------------------------------+--------------------------------------
Comment (by tscrim):
Replying to [comment:13 nbruin]:
> The ticket states that `ComplexNumber(complex(...))` doesn't work and
proceeds by implementing a more elaborate string parser. That's not the
most obvious way of soving the ticket:
> - a python `complex` already has a nice `.real()` and `.imag()`, so
stuffing them together in a string to just pry them apart is not a smart
move. Doing
> {{{
> if isinstance(s_real, complex):
> s_real, s_imag = s_real.real(), s_real.imag()
> }}}
> makes much more sense to solve the problem at hand.
This is already how I've done it done in the current patch.
> - The fact that `ComplexNumber` would assemble a complex number from
numerical input by converting to a string is ludicrous in its own right:
If you're handed real and imaginary parts in numerical form, you should
NOT be converting to strings as an intermediate. That's just asking for
precision loss (and horrible performance).
That was the original implementation with two reals as input, and I
haven't changed that. Nevertheless, I agree that it should be changed (see
below).
>
> I realize that we have the documentation:
> {{{
> def create_ComplexNumber(s_real, s_imag=None, int pad=0, min_prec=53):
> Return the complex number defined by the strings s_real and
> s_imag as an element of ``ComplexField(prec=n)``,
> where n potentially has slightly more (controlled by pad) bits than
> given by s.
> }}}
> According to that documentation, the proposed input is not valid
anyway. By changing that you're changing the interface the routine offers.
That's fine, but once you start changing it, you should ''improve'' it.
>
> Note that `CC(complex("1+2j"))` already works. By the looks of it,
`CC.__call__` is already taking a much saner approach. Perhaps
`ComplexNumber` should share more with that routine? Or be documented that
people should really use `CC(...)`? or perhaps `ComplexNumber` can be
deprecated altogether?
How about we check if the input is a (pair of) `str`, and if not, then it
just feeds it to `CC` in an appropriate fashion? I don't think we should
deprecate it because the naive person IMO would likely look for
`ComplexNumber` before `CC`.
Volker, good point. I don't use regex too often so it's never really
something I think of. I'll do that on the next patch.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13110#comment:14>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
