#9582 closed defect (fixed)
Term order discrepancy in random test on OS X
Reported by: | mpatel | Owned by: | mvngu |
---|---|---|---|
Priority: | blocker | Milestone: | sage-4.5.2 |
Component: | doctest coverage | Keywords: | |
Cc: | cwitty, ddrake, jhpalmieri, burcin | Merged in: | sage-4.5.2.rc0 |
Authors: | Carl Witty | Reviewers: | Mitesh Patel |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
Reported by John Palmieri on sage-release:
a 64 bit Mac OS X 10.6.4 box: one failure: sage -t -long "devel/sage/sage/symbolic/random_tests.py" ********************************************************************** File "/Applications/sage_builds/sage-4.5.2.alpha0/devel/sage/sage/ symbolic/random_tests.py", line 236: sage: random_expr(50, nvars=3, coeff_generator=CDF.random_element) Expected: factorial(floor((-0.314177274493 + 0.144437996366*I)/cosh(-v1^2*e/ v3) + cos((-0.708874026302 - 0.954135400334*I)*v3) - zetaderiv(-0.228070288671 + 0.33842966472*I, 0.520184609653 - 0.734276246499*I)))^(-arccoth(-abs(((-0.804514286089 - 0.0293247734576*I)*v1 + (-0.804514286089 - 0.0293247734576*I)*v3 - 1.0)*elliptic_ec((-0.0263902659909 + 0.153261789843*I)*arccot(pi*catalan))))) Got: factorial(floor((-0.314177274493 + 0.144437996366*I)/cosh(-v1^2*e/ v3) - zetaderiv(-0.228070288671 + 0.33842966472*I, 0.520184609653 - 0.734276246499*I) + cos((-0.708874026302 - 0.954135400334*I)*v3)))^(- arccoth(-abs(((-0.804514286089 - 0.0293247734576*I)*v1 + (-0.804514286089 - 0.0293247734576*I)*v3 - 1.0)*elliptic_ec((-0.0263902659909 + 0.153261789843*I)*arccot(pi*catalan))))) ********************************************************************** Looks like a discrepancy in the order terms are printed.
Acccording to Dan Drake:
I'm seeing that on bsd.math too. This is related to #9514, which was supposed to fix this, but evidently doesn't, on OS X at least.
Related: #9514.
Attachments (1)
Change History (13)
comment:1 Changed 12 years ago by
- Cc burcin added
comment:2 Changed 11 years ago by
Evaluating cos(x) + zeta(x)
in Sage 4.5.2.alpha0 gives
zeta(x) + cos(x)
on sage.math.cos(x) + zeta(x)
on bsd.math.
Is this representative of the underlying problem?
comment:3 Changed 11 years ago by
comment:4 Changed 11 years ago by
On Sage 4.4.4 on OS X 10.6:
sage: cos(x)+zeta(x) cos(x) + zeta(x) sage: zeta(x)+cos(x) cos(x) + zeta(x) sage: version() 'Sage Version 4.4.4, Release Date: 2010-06-23'
So this may have been a problem for a while?
comment:5 Changed 11 years ago by
Maybe so. Maybe it was just exposed with new tests?
Changed 11 years ago by
comment:6 follow-ups: ↓ 7 ↓ 9 Changed 11 years ago by
- Status changed from new to needs_review
If we decide that the actual problem (different printing across platforms) is not a regression, and doesn't have to be fixed in this release, then I've attached a patch that works around the problem (by modifying the doctest to produce an output that prints the same on my Linux box and on bsd.math).
If you do apply my patch, then either this ticket should not be closed, or another one should be opened about the printing order issue.
comment:7 in reply to: ↑ 6 Changed 11 years ago by
- Reviewers set to Mitesh Patel
- Status changed from needs_review to positive_review
Replying to cwitty:
If we decide that the actual problem (different printing across platforms) is not a regression, and doesn't have to be fixed in this release, then I've attached a patch that works around the problem (by modifying the doctest to produce an output that prints the same on my Linux box and on bsd.math).
This seems reasonable. Are there any objections? The workaround patch works for me on bsd, sage, and t2.math.
If you do apply my patch, then either this ticket should not be closed, or another one should be opened about the printing order issue.
I'll give this ticket a positive review, merge it in 4.5.2.rc0, close it, and open a new one for the printing order problem.
comment:8 Changed 11 years ago by
- Merged in set to sage-4.5.2.rc0
- Resolution set to fixed
- Status changed from positive_review to closed
comment:9 in reply to: ↑ 6 Changed 11 years ago by
comment:10 Changed 11 years ago by
Burcin, since we haven't released 4.5.2.rc0 yet, I'm happy to make changes to it, e.g., merging a different patch. Just let us know within a day or so. I apologize for not giving you more time to examine this ticket.
comment:11 Changed 11 years ago by
I've "qfinished" 4.5.2.rc0, and we will release it soon. Shall we continue at #9632?
comment:12 Changed 11 years ago by
Yes, I couldn't see any quick fix which wouldn't effect performance. Ordering of the terms is already a big performance bottleneck in Python. I'd like to fix things properly once instead of adding kludges all around, but I don't have time to do that right now.
I've been sidetracked by other pynac problems since. Sorry for keeping quiet all this time and thanks for your efforts.
Unlikely that this has anything to do with #9514. The symptom of #9514 was getting totally different terms, and the cause was that it made a list of all known symbolic functions [sin, cos, factorial, ...], and randomly picked the third element (say) from the list -- but on different systems, the third element might be factorial, or it might be cos.
If it's producing mathematically equal terms that only print differently, which seems to be the case here, the cause is probably some system dependency in the pynac simplification or printing routines.