#19063: Coercions and basic arithmetic for complex balls
-------------------------------------+-------------------------------------
Reporter: mmezzarobba | Owner:
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.9
Component: numerical | Resolution:
Keywords: arb | Merged in:
Authors: Marc Mezzarobba | Reviewers: Clemens Heuberger
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/cheuberg/19063-acb | a33ceb40f76cd57791ad9e950fec234373278057
Dependencies: #18546 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by mmezzarobba):
Replying to [comment:10 cheuberg]:
> I have now reviewed this patch and added a few reviewer commits.
Thanks!
> Questions:
>
> * `ComplexBall.__init__`: why `Element.__init__` instead of
`RingElement.__init__`
Because I neglected to change it after changing the parent class. (I hate
Python...)
> * `.some_elements`: Is `1/3` intentional (this is an elaborate way of
writing 0 in python)
It wasn't intentional.
> * Why is the representation `real - imag*I` restricted to exact negative
imaginary parts and does not apply to
> `1 + [-0.333]*I`
The old version would return things like `1.000000000000000 + -
0.5000000000000000*I` for exactly representable imaginary parts. I only
implemented a minimal fix, thinking that the version with `... + [...]`
was clear enough and perhaps clearer otherwise (especially for intervals
containing zero), but I have no strong feelings either way.
> * `.__contains__`, `.contains_exact`: why do we have two distinct
methods here? Why is an integer or a rational as the argument of
`.__contains__` not handeled separately by the relevant .acb functions?
The idea was to have a version that first converts its argument to a ball
(and thus can accept a wide range of argument types), but may not
recognize that the argument is contained in the other ball if the
conversion is not precise enough, and a version for which a result of
`False` always guarantees that the argument is not in the ball. We could
just document for which argument types the result of `in` is guaranteed to
be accurate, but I felt it'd be clearer that way. Here too, I'm open to
discussion if you don't like that choice.
> Apart from that, a few documentation issues:
>
> * `_complex_mpfr_field_`: missing INPUT: section (parameter `parent`)
>
> * `_real_mpfi_`: missing INPUT: section (parameter parent), One-
sentence-description mentions "real number" instead of "real interval".
>
> * `_mpfr_`: missing INPUT: section (parameter `parent`)
>
> * `.mid`, `.squash`: missing OUTPUT: section
>
> * `.mid` should have "see also" section (`.squash`)
>
> * `.identical` refers to a method `contains` which does not exist.
>
> * `.contains_exact`, `.identical`, `.overlaps`: missing INPUT: section
(parameter `other`)
Thanks. But note that the formal requirement of pointless INPUT/OUTPUT
sections in docstrings is apparently going to be relaxed (#19041), so I'm
not sure we need them INPUT sections every time you noted they were
missing.
--
Ticket URL: <http://trac.sagemath.org/ticket/19063#comment:11>
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.
For more options, visit https://groups.google.com/d/optout.
