#10766: Update ECL to the latest upstream release.
-------------------------------------------------+--------------------------
Reporter: drkirkby | Owner: AlexGhitza
Type: defect | Status: positive_review
Priority: major | Milestone: sage-4.7
Component: algebra | Keywords:
Author: François Bissey | Upstream: N/A
Reviewer: David Kirkby, Karl-Dieter Crisman | Merged:
Work_issues: |
-------------------------------------------------+--------------------------
Comment(by fbissey):
Since I have put them I think I should explain my choices of ellipses (or
not).
First we are doing numerical computation here, and as far as I can see,
not in arbitrary precision. In that context having a lot of significant
figures is usually useless. It just test your FPU and your implementation.
So for example we now have
1.5430806348152437 instead of [[BR]]
1.543080634815244, big deal, next iteration will probably have something
different there, it may very well revert to print one less decimal which
is probably the only difference here. If we had printed as many decimals
with the old ecl we may have had the same result. By putting ellipses here
I am taking away the last few significant figures which are quite possibly
arbitrary. I guess I could check with wolfram alpha at an arbitrary
precision as well.
If we had something like 1.85 and 1.849999999 that would more problematic.
But it is a symptom of the fact that we probably should just test a number
of significant figures. Instead of having the raw results print 10
significant figures for example, more if you do arbitrary precision
computations.
For this one I put the exact answer returned by maxima:
{{{
sage -t -force_lib "devel/sage-main/sage/calculus/calculus.py"
**********************************************************************
File "/usr/share/sage/devel/sage-main/sage/calculus/calculus.py", line
677:
sage: f.nintegrate(x,0,1)
Expected:
(-480.00000000000011, 5.3290705182007538e-12, 21, 0)
Got:
(-480.00000000000006, 5.3290705182007538e-12, 21, 0)
**********************************************************************
}}}
I did that because of the text that goes with the test:
{{{
Despite appearance, `f` is really very close to 0, but one
gets a nonzero value since the definition of
``float(f)`` is that it makes all constants inside the
expression floats, then evaluates each function and each arithmetic
operation using float arithmetic::
sage: float(f)
-480.0
Computing to higher precision we see the truth::
sage: f.n(200)
-7.4992740280181431112064614366622348652078895136533593355718e-13
sage: f.n(300)
-7.49927402801814311120646143662663009137292462589621789352095066181709095575681963967103004e-13
Now numerically integrating, we see why the answer is wrong::
sage: f.nintegrate(x,0,1)
(-480.00000000000006, 5.3290705182007538e-12, 21, 0)
It is just because every floating point evaluation of return -480.0
in floating point.
}}}
I thought it would be best to have the exact value. However anything
starting with -480.00 would clearly have been good enough.
The test in symbolic/integration/integral.py is more interesting. It
documented a behavior of ecl/maxima when you used ".expand" or not and the
influence it had on results, before the patch:
{{{
Check if #6189 is fixed (which, by the way, also
demonstrates it's not always good to expand)::
sage: n = N; n
<function numerical_approx at ...>
sage: F(x) = 1/sqrt(2*pi*1^2)*exp(-1/(2*1^2)*(x-0)^2)
sage: G(x) = 1/sqrt(2*pi*n(1)^2)*exp(-1/(2*n(1)^2)*(x-n(0))^2)
sage: integrate( (F(x)-F(x))^2, x, -infinity, infinity).n()
0.000000000000000
sage: integrate( ((F(x)-G(x))^2).expand(), x, -infinity,
infinity).n()
-6.26376265908397e-17
sage: integrate( (F(x)-G(x))^2, x, -infinity, infinity).n()
0
}}}
Now the result is the same whether we expand or not. So the test is [[BR]]
1) moot[[BR]]
2) virtually reopen #6189 since we now always have a non-zero result[[BR]]
I think for this one we need a better example and a way of making this
integral behave.
In summary most of the numerical noise observed is due to the fact that
ecl-11.1.1 print one more decimal place by default. Because this may
change and the level of precision doesn't make any sense for most purpose
I decided to put ellipses. The more juicy bits where I didn't do that are
open to interesting discussion.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10766#comment:21>
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.
