Ticket #12068 (closed enhancement: fixed)
Numerator for symbolic expression shouldn't use maxima
| Reported by: | hivert | Owned by: | hivert |
|---|---|---|---|
| Priority: | major | Milestone: | sage-5.0 |
| Component: | symbolics | Keywords: | numerator, denominator |
| Cc: | Work issues: | ||
| Report Upstream: | N/A | Reviewers: | Burcin Erocal, Florent Hivert, Karl-Dieter Crisman |
| Authors: | Florent Hivert, Burcin Erocal | Merged in: | sage-5.0.beta2 |
| Dependencies: | Stopgaps: |
Description (last modified by kcrisman) (diff)
The code for numerator is currently
def numerator(self): """ Returns the numerator of this symbolic expression. If the [...] """ return self.parent()(self._maxima_().num())
Using Pynac should be much faster.
The patch wraps numer, denom, numer_denom and normal from GiNaC and fixes a bunch of wrong sphinx markup in expression.pyx.
Apply trac_12068-numer_denom_normal-ginac-fh.patch and trac_12068-reviewer.patch.
Attachments
Change History
comment:1 Changed 18 months ago by hivert
- Owner changed from burcin to hivert
- Authors set to Florent Hivert
comment:3 follow-up: ↓ 4 Changed 18 months ago by burcin
- Reviewers set to Burcin Erocal
- Summary changed from Numerator for symbolic expression should'nt use maxima to Numerator for symbolic expression shouldn't use maxima
Looks good to me. It would be better to use elif in line 6480 and 6481. Otherwise, positive review once the tests pass.
Thank you for working on this.
comment:4 in reply to: ↑ 3 Changed 18 months ago by hivert
Replying to burcin:
Looks good to me. It would be better to use elif in line 6480 and 6481. Otherwise, positive review once the tests pass.
Done !
comment:5 Changed 18 months ago by hivert
I got a all test passed on my laptop except a timeout in sage/schemes/elliptic_curves/ell_rational_field.py however relaunching a non parallel test on this single file gives:
sage -t "sage/schemes/elliptic_curves/ell_rational_field.py"
[89.8 s]
----------------------------------------------------------------------
All tests passed!
Total time for all tests: 89.8 seconds
comment:6 follow-up: ↓ 7 Changed 18 months ago by burcin
- Description modified (diff)
- Authors changed from Florent Hivert to Florent Hivert, Burcin Erocal
Declaring py_pow as an int caused problems with attachment:trac_12068-numer_denom_ginac-fh.patch. py_object_from_numeric() returns a PyObject. Assigning the return value to an int worked because Cython was creating a temporary PyObject and trying to convert that to an int. This failed if the exponent was not an integer.
attachment:trac_12068-denominator.patch fixes this problem and handles expressions which contain only a power.
Florent can you review my patch?
Apply attachment:trac_12068-numer_denom_ginac-fh.patch, attachment:trac_12068-denominator.patch
comment:7 in reply to: ↑ 6 Changed 18 months ago by hivert
Replying to burcin:
Florent can you review my patch?
Thanks for fixing my mistake. Unfortunately, because I choose to duplicate the code to speedup numerator_denominator, I also duplicate the mistake. You corrected only one. I'll upload a patch fixing everything.
comment:8 Changed 18 months ago by hivert
- Description modified (diff)
Hi Burcin,
The uploaded patch should fix everything. attachment:trac_12068-numer_denom_fix-fh.patch contains my modifications on top of yours and attachment:trac_12068-numer_denom_ginac-folded-fh.patch contains everything folded.
Your turn to review ;-)
comment:9 follow-up: ↓ 10 Changed 18 months ago by burcin
- Status changed from needs_review to positive_review
- Reviewers changed from Burcin Erocal to Burcin Erocal, Florent Hivert
It all looks good. The declaration cdef int py_pow is redundant in numerator_denominator(), but I'll switch to positive review anyway.
comment:10 in reply to: ↑ 9 Changed 18 months ago by hivert
- Status changed from positive_review to needs_work
Bi Burcin,
Replying to burcin:
It all looks good. The declaration cdef int py_pow is redundant in numerator_denominator(), but I'll switch to positive review anyway.
The following diff
-
sage/symbolic/expression.pyx
diff --git a/sage/symbolic/expression.pyx b/sage/symbolic/expression.pyx
a b cdef class Expression(CommutativeRingEle 1867 1867 assured that if True or False is returned (and proof is False) then 1868 1868 the answer is correct. 1869 1869 1870 INPUT: :1870 INPUT: 1871 1871 1872 1872 ntests -- (default 20) the number of iterations to run 1873 1873 domain -- (optional) the domain from which to draw the random values
broke the doc. So I had to fix my patch. Doing so I discovered a few more typos and fixed them once for all. In the process I ended up folding the patch for #12072.
So please re review. Sorry for the double review.
Florent
comment:11 Changed 18 months ago by hivert
- Status changed from needs_work to needs_review
- Description modified (diff)
Please re-review. Compared to my previous patch, I
- wrapped normal;
- removed the unused py_pow declaration;
- fixed a bunch of doc typos.
Again sorry for the extra work,
Florent
comment:12 follow-up: ↓ 14 Changed 16 months ago by kcrisman
- Status changed from needs_review to positive_review
- Reviewers changed from Burcin Erocal, Florent Hivert to Burcin Erocal, Florent Hivert, Karl-Dieter Crisman
The changes to the previous patch seem fine, docs are good, tests pass. In fact, it's a very nice patch.
The only problem I spied is in the last hunk:
- ``self`` -- the symbolic expression converting from
- ``target`` -- (default None) the symbolic expression
is too far indented. If you're going to fix all of this stuff, you might as well make these at the same indentation level as INPUT, such as in the second-to-last hunk.
In fact, I'm attaching a reviewer patch to fix this.
I wonder if there is a more 'obvious' name for normalize that could be an alias... anyway, not for this ticket. Assuming that Burcin has no objections, positive review other than this.
comment:13 Changed 16 months ago by kcrisman
- Description modified (diff)
comment:14 in reply to: ↑ 12 ; follow-up: ↓ 15 Changed 16 months ago by hivert
Hi Karl-Dieter,
Replying to kcrisman:
The changes to the previous patch seem fine, docs are good, tests pass. In fact, it's a very nice patch.
Thanks !
The only problem I spied is in the last hunk:
- ``self`` -- the symbolic expression converting from
- ``target`` -- (default None) the symbolic expression
is too far indented. If you're going to fix all of this stuff, you might as well make these at the same indentation level as INPUT, such as in the second-to-last hunk.
In fact, I'm attaching a reviewer patch to fix this.
Should't someone review your trivial reviewer patch before putting positive review ? Anyway, It is an obvious patch and I did review it. So I confirm your positive review.
I wonder if there is a more 'obvious' name for normalize that could be an alias... anyway, not for this ticket. Assuming that Burcin has no objections, positive review other than this.
In every CAS I used, I've always been confused by simplify, normal, combine... I guess Sage isn't an exception.
comment:15 in reply to: ↑ 14 Changed 16 months ago by kcrisman
In fact, I'm attaching a reviewer patch to fix this.
Should't someone review your trivial reviewer patch before putting positive review ? Anyway, It is an obvious patch and I did review it. So I confirm your positive review.
No, reviewers are usually allowed to make VERY trivial changes, esp. to fix doc, without 'formal' other review, otherwise we would take even longer to review things than normal. Naturally, anyone could decide that "reviewer patch X needs review" if they felt it was nontrivial.
comment:16 Changed 16 months ago by jdemeyer
- Status changed from positive_review to closed
- Resolution set to fixed
- Merged in set to sage-5.0.beta2


Ginac's behavior is not the same has Maxima: given 1 + 1/(x + 1)
I think both are useful. My patch keeps the current behavior. Is this what we want ?
Florent