#19568: arb balls should have the precision of the parent
-------------------------------------+-------------------------------------
Reporter: jdemeyer | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: sage-6.10
Component: interfaces | Resolution:
Keywords: | Merged in:
Authors: Jeroen Demeyer | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/jdemeyer/arb_balls_should_have_the_precision_of_the_parent|
638f7f581a72056c39d013e4b46cce500176a710
Dependencies: #19152 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by jdemeyer):
Replying to [comment:3 mmezzarobba]:
> IMO saying that “arb balls can have a precision different from their
parent” isn't the right way to think about the issue. For example,
`RealBallField(100)(1)` and `RealBallField(200)(1)` both have midpoints
whose mantissa fits on 1 bit and zero radius: what is their “precision”?
By definition, the precision is the precision of the parent. There is
nothing confusing about this. It is exactly like everything else in Sage.
> I don't find the way things currently work particularly confusing, while
I think it can be useful in “advanced” use (to compute the result of a
subtraction involving cancellation, say).
We shouldn't aim in the first place to "advanced" use, we should aim in
the first place for intuitive use. This means in particular being
compatible with the rest of Sage.
> I should also say that real balls won't really “have the precision of
their parent” even after your change: at the very least it will still be
possible to create balls whose midpoint's precision is less than the
precision of the parent—and that's a good thing
That's an implementation detail. It doesn't matter from the user's point
of view.
> So personally I'm certainly not going to give this ticket
positive_review. That being said, I have no strong objection either to
rounding integers etc. by default when creating new balls. It just makes
things a bit less flexible for no good reason.
There is a good reason, read the ticket description.
--
Ticket URL: <http://trac.sagemath.org/ticket/19568#comment:4>
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.
