Opened 12 years ago
Closed 12 years ago
#9689 closed defect (fixed)
Numerical noise on devel/sage-main/sage/symbolic/expression.pyx computing sinh(1)
Reported by: | drkirkby | Owned by: | mvngu |
---|---|---|---|
Priority: | blocker | Milestone: | sage-4.5.3 |
Component: | doctest coverage | Keywords: | |
Cc: | jhpalmieri | Merged in: | sage-4.5.3.alpha2 |
Authors: | David Kirkby | Reviewers: | John Cremona |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
Whilst there is no complete 64-bit build of Sage on Solaris x86, a sufficiently large part of Sage does build (with a few changes) on Solaris 10 x86. When built on 'fulvia', a Dell Optiplex with Xeon processors, there was a numerical noise issue - see #9099
sage -t -long devel/sage/sage/symbolic/expression.pyx ********************************************************************** File "/home/palmieri/fulvia/sage-4.5.2.rc0/devel/sage-main/sage/symbolic/expression.pyx", line 498\ 3: sage: maxima('sinh(1.0)') Expected: 1.175201193643801 Got: 1.175201193643802
A computation with Mathematica, using 60 digits of precision gives
In[2]:= N[Sinh[1],60] Out[2]= 1.17520119364380145688238185059560081515571798133409587022957
The absolute error on Solaris x86 is slightly higher than seen on some other systems, but this is still a perfectly acceptable result.
This should be fairly easy to fix. I'll make a patch later today
Dave
Attachments (1)
Change History (12)
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
- Description modified (diff)
- Status changed from new to needs_review
- Summary changed from Numerical noise on devel/sage-main/sage/symbolic/expression.pyx to Numerical noise on devel/sage-main/sage/symbolic/expression.pyx computing sinh(1)
Changed 12 years ago by
Solves the numerical noise issue computing sinh(1.0). The archsinh case is more complex, and will be on another ticket.
comment:3 Changed 12 years ago by
It's not very pretty, but
abs(float(maxima('asinh(1.0)')) - 0.881373587019543) < 1e-15
or
maxima('abs(asinh(1.0) - 0.881373587019543)') < 1e-15
work for the other test. Or:
sage: float(maxima('asinh(1.0)')) 0.8813735870195429...
comment:4 Changed 12 years ago by
Or replace "float" with "RR", etc.
comment:5 Changed 12 years ago by
Yes, we can get this to pass, but that is just covering up a bug, as the number should never be printed as .8813735870195429
It is a numerically correct result, but it is not printed the way one would expect a piece of software to print the number.
Carl Witty is of the opinion this is either a Maxima or ECL bug
http://groups.google.com/group/sage-devel/msg/aa318e11e84afe8d?hl=en
I think its better to leave the asinh(1.0)
case failing. It will be a constant reminder we need to get a real solution, not hack the doctest to get it to pass.
Ultimately, I feel the doctest has discovered a bug, which is what a good test should do.
Dave
comment:6 Changed 12 years ago by
comment:7 Changed 12 years ago by
I created #9693 to resolve the leading zero problem and are going to copy the problem to the ECL and Maxima mailing lists, to see if we get any response.
Dave
comment:8 follow-up: ↓ 9 Changed 12 years ago by
- Status changed from needs_review to positive_review
This looks fine to me and passed tests (in that file) on both 32-bit and 64-bit ubuntu.
comment:9 in reply to: ↑ 8 Changed 12 years ago by
Replying to cremona:
This looks fine to me and passed tests (in that file) on both 32-bit and 64-bit ubuntu.
Thank you for the review John.
Dave
comment:10 Changed 12 years ago by
- Priority changed from major to blocker
- Reviewers set to John Cremona
comment:11 Changed 12 years ago by
- Merged in set to sage-4.5.3.alpha2
- Resolution set to fixed
- Status changed from positive_review to closed
I just realise the second failure shown on #9099
is the same file (devel/sage-main/sage/symbolic/expression.pyx) as this simple numerical noise issue. Hopefully be solved too. That's a less obvious problem to solve though.
Any ideas anyone?