#19063: Coercions and basic arithmetic for complex balls
-------------------------------------+-------------------------------------
Reporter: mmezzarobba | Owner:
Type: enhancement | Status: needs_work
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 cheuberg):
Replying to [comment:11 mmezzarobba]:
> > Questions:
> >
> > * `ComplexBall.__init__`: why `Element.__init__` instead of
`RingElement.__init__`
>
> Because I neglected to change it after changing the parent class. (I
hate Python...)
If I remember correctly, there is some reason not to use `super`.
> > * 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.
No strong feelings from my side; I was just wondering reading the code.
For intervals containing the zero, it might indeed be strange.
>
> > * `.__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.
I think that `rational in ball` and `integer in ball` should give correct
results in any case.
>
> > 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.
I know; the question is what is obvious and what not. My feelings are not
very strong here.
--
Ticket URL: <http://trac.sagemath.org/ticket/19063#comment:13>
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.
