#18560: Upgrade arb to 2.6.0
-------------------------------------+-------------------------------------
       Reporter:  cheuberg           |        Owner:
           Type:  enhancement        |       Status:  needs_work
       Priority:  major              |    Milestone:  sage-6.8
      Component:  packages:          |   Resolution:
  optional                           |    Merged in:
       Keywords:  arb                |    Reviewers:
        Authors:  Clemens Heuberger  |  Work issues:
Report Upstream:  N/A                |       Commit:
         Branch:                     |  3b534cbb91702fb1f7fd1dfd4b69974bb0411b4e
  u/cheuberg/libs/arb-2.6.0          |     Stopgaps:
   Dependencies:                     |
-------------------------------------+-------------------------------------

Comment (by jdemeyer):

 Replying to [comment:23 fredrik.johansson]:
 > 1. Print doctest examples with a few digits less than the computed
 precision, so that most of the radius bound in the printed output comes
 from the decimal rounding. This will only rarely cause a last digit to
 flip over unpredictably. The disadvantage is that the doctest does not
 show the actual computed interval. On the other hand, the output is a
 neater representation of the mathematical value. For example, if you print
 pi to 10 digits, you should always get [3.141592654 +/- 4.11e-10] beyond a
 certain working precision (from 43 bits, in fact) since the actual
 difference between pi and 3.141592654 is 4.102...e-10.
 If we go with this, I would not make a difference between normal
 interactive Sage output and doctests. Just print balls with fewer digits
 always, like we already do for `RR`.

 > 2. Implement a doctest directive that parses intervals and checks
 whether the actual and expected outputs overlap (this could also take a
 tolerance and verify that the new actual output is not too imprecise, e.g.
 53-bit pi suddenly coming out as [3.1 +/- 0.1]).

 This would require writing a much more complicated doctest parser
 (remember you don't just want balls, but also polynomials/lists/matrices
 with ball coefficients and then you'll also want support for complex
 numbers, mpfi intervals and who knows what), I don't think this is a
 realistic solution.

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