#9343: Upgrade PARI to svn snapshot 12577 - a pre-release of PARI 2.4.3.
------------------------------------------------------------------------------------------+
Reporter: was
| Owner: jdemeyer
Type: enhancement
| Status: needs_work
Priority: major
| Milestone: sage-4.6
Component: packages
| Keywords:
Author: Robert Bradshaw, John Cremona, Jeroen Demeyer, William Stein,
David Kirkby | Upstream: N/A
Reviewer:
| Merged:
Work_issues:
|
------------------------------------------------------------------------------------------+
Comment(by rishi):
Replying to [comment:238 cremona]:
> Replying to [comment:237 drkirkby]:
> > Replying to [comment:236 davidloeffler]:
> >
> > > Maybe rather than directly testing the answer, one could do
something like this:
> > > {{{
> > > sage: x = [calculation]; abs(x - 2.975975720740376676146967119) <
10^(-27)
> > > True
> > > }}}
> It is real. The list is the list of values of {{{z^2}}} as z runs over
the roots of {{{f = x^5 + x + 17}}}, which has exactly one real root,
listed first. Apart from precision the output should be the same as
> {{{
> sage: [z[0]^2 for z in f.roots(CC)]
> [2.97572074037668, -2.40889943716139 + 1.90254105303505*I,
-2.40889943716139 - 1.90254105303505*I, 0.921039066973047 -
3.07553311884578*I, 0.921039066973047 + 3.07553311884578*I]
> }}}
> The function being tested is rather general, so one could not expect the
function's code to test for this special case (I think). Still, it is
disappointing that the imaginary part is not a better approximation to
zero than it is.
>
It is a complex embedding, so the output is a ComplexNumber, ideally with
real part zero. The precision is 100 bit. This indeed makes 10^{-27} a bit
disappoint.
>
> >
> > I might guess the small imaginary component should not be there at
all, but would my guess be right? I'm not a mathematician.
> >
> > Only when I know the answer to that question do I feel able to comment
on a test.
> >
> > Given the number of digits that are printed (> 16), this would suggest
to me that arbitrary precision maths is being used, and not just a
floating point processor. If so, the answer should be the same
irrespective of whether the machine is 32-bit or 64-bit. Rounding errors
occur in floating point processors - they do not on integer arithmetic if
done properly.
> >
> > If this is being done with just an FPU, then printing these number of
digits is a bit pointless.
> >
> > Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9343#comment:239>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
