#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 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”?
 The way I view it, they have none by themselves, and having
 `RealBallField`s of different precisions is just a convenient way of
 specifying the precision at which the results of operations on balls
 should be rounded.

 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). 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, but I'm not sure it is less confusing than the behavior you
 are trying to change.

 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.

--
Ticket URL: <http://trac.sagemath.org/ticket/19568#comment:3>
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.

Reply via email to