Opened 12 years ago
Closed 11 years ago
#6559 closed enhancement (fixed)
Real domain for symbolic variables
Reported by: | gmhossain | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-4.3.3 |
Component: | symbolics | Keywords: | pynac |
Cc: | Merged in: | sage-4.3.3.alpha1 | |
Authors: | Golam Mortuza Hossain, Burcin Erocal | Reviewers: | Karl-Dieter Crisman, Ross Kyprianou, Minh Van Nguyen |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
In new symbolics, the default symbolic variables are complex. However, sometime it is useful/desirable to make the domain of variables to be real.
Currently, there are no way to specify the domain of variables in Sage although underlying Ginac allows it. For example: following would to be good to have.
sage: var('x,y,z', domain='real')
Instructions for installing these patches (sage-4.1.1)
(1) Pynac patch
(a) Get the pynac spkg
http://sage.math.washington.edu/home/burcin/pynac/pynac-0.1.8.p2.spkg
(b) Apply the pynac patch for enhanced symbols
http://www.math.unb.ca/~ghossain/texname-and-domain-of-symbols-pynac.patch
(c) install the patched spkg in Sage.
OR if you are feeling lazy, you can directly install my patched copy of pynac from here
http://www.math.unb.ca/~ghossain/pynac-0.1.8.p2-symbols.spkg
(2) Sage patch:
Apply the attached sage patch after modified pynac spkg is installed
Notes:
#6403 will also be resolved by this patch
#6340 patch conflicts with this patch. This patch here should supersede the patch at #6340.
Attachments (4)
Change History (29)
comment:1 Changed 12 years ago by
Changed 12 years ago by
comment:2 Changed 12 years ago by
- Description modified (diff)
- Summary changed from Real domain for symbolic variables to [with patch, needs review] Real domain for symbolic variables
comment:3 Changed 11 years ago by
How does this relate to pynac 0.1.9 which is in Sage 4.2.1? ~ Adam
comment:4 Changed 11 years ago by
- Report Upstream set to N/A
- Status changed from needs_review to needs_work
Applied patch and the following errors were returned:
applying trac_6559-domain-and-latex_name-for-variable.patch patching file sage/calculus/var.pyx Hunk #1 FAILED at 0 Hunk #2 FAILED at 8 Hunk #4 FAILED at 81 3 out of 4 hunks FAILED -- saving rejects to file sage/calculus/var.pyx.rej patching file sage/symbolic/pynac.pyx Hunk #1 FAILED at 454 Hunk #2 FAILED at 504 2 out of 2 hunks FAILED -- saving rejects to file sage/symbolic/pynac.pyx.rej patching file sage/symbolic/ring.pyx Hunk #6 succeeded at 769 with fuzz 1 (offset -2 lines). patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_6559-domain-and-latex_name-for-variable.patch
comment:5 Changed 11 years ago by
- Milestone set to sage-4.3.1
- Status changed from needs_work to needs_review
- Summary changed from [with patch, needs review] Real domain for symbolic variables to Real domain for symbolic variables
comment:6 Changed 11 years ago by
- Status changed from needs_review to needs_work
- Work issues set to needs rebase
Changed 11 years ago by
comment:7 Changed 11 years ago by
- Keywords pynac added
- Work issues needs rebase deleted
I uploaded a revised version of Golam's patch at attachment:trac_6559-domain-and-latex_name-for-variable.take2.3.patch, and a referee patch at attachment:trac_6559-referee.patch.
The changes in the revised patch over Golam's version are
- rebased to 4.3.rc0
- removed
sage.symbolic.ring.SR.new_var()
andsage.symbolic.ring.is_ComplexVariable()
functions. The first is same asSR.symbol()
and I don't see a use for the second, since all variables are complex. :) - removed pickling changes in sage.symbolic.expression.Expression, since unpickling in this case could create a new variable with the same name as an existing one, but with a different domain. This would lead to rather confusing situations.
The referee patch reorganizes the new code a little to make it more efficient. Apparently the new variable creation is an important operation and being sloppy here greatly increases doctest timings. It also adds new methods like _is_positive()
, _is_real()
to the expression class to allow querying for more properties.
Only the patches
- attachment:trac_6559-domain-and-latex_name-for-variable.take2.3.patch and
- attachment:trac_6559-referee.patch
should be applied.
This ticket depends on the new pynac package here:
http://sage.math.washington.edu/home/burcin/pynac/pynac-0.1.11.spkg
which in turns depends on the patches at #7822, #7876, #7363, #7955, #7957, #7916 and #6465 (in that order).
The changes here seem to slow down the maxima interface dramatically, so I'm leaving this as needs work for now.
Changed 11 years ago by
comment:8 Changed 11 years ago by
- Status changed from needs_work to needs_review
New patches up, ready for review.
Apply only:
- attachment:trac_6559-domain-and-latex_name-for-variable.take2.3.patch
- attachment:trac_6559-referee.take2.patch
Depends on the pynac package here:
http://sage.math.washington.edu/home/burcin/pynac/pynac-0.1.11.spkg
and the tickets #7822, #7876, #7363, #7955, #7957, #7916 and #6465 (in that order).
comment:9 Changed 11 years ago by
I applied the patches in this order:
$ hg qseries trac_7999-encoding.patch trac_6961-psi.patch trac_7822-py_log.take2.patch trac_7876-pynac_print.take2.patch trac_7363-mul_coeff.patch trac_7955-integrate_latex.patch trac_7957-pynac_exceptions.patch trac_7916-same_name_method.take2.patch trac_6465-chain_rule.take2.patch trac_6465-moves-integration-into-sfunction-subclass.take2.patch trac_6465-integral.patch trac_6559-domain-and-latex_name-for-variable.take2.3.patch trac_6559-referee.take2.patch
There's only one failure (sage -tp, not long) in arith.py, which is a documentation thing and unrelated to this ticket.
comment:10 Changed 11 years ago by
Is it likely that the rebase referred to in #6961 might affect other patches than just that one? Read that before refereeing, in any case.
comment:11 Changed 11 years ago by
I can't even begin to say where these are from... but
sage/misc/citation.pyx", line 60: sage: get_systems('integrate(x^2, x)') Expected: ['ginac', 'Maxima'] Got: ['MPFI', 'ginac', 'Maxima']
sage/symbolic/random_tests.py", line 206: sage: random_expr(5, verbose=True) Expected: About to apply <built-in function add> to [v1, v1] About to apply <built-in function div> to [-1/3, 2*v1] -1/6/v1 Got: About to apply <built-in function add> to [v1, v1] About to apply <built-in function div> to [94, 2*v1] 47/v1
seem to be related to just random changes in 4.3.1, while
sage/functions/generalized.py", line 239: sage: t.subs(x=1) Expected: 2 Got: heaviside(x) + 1
and a few friends seem to be related to something in pickling changing (I get no other errors with things like that).
In addition, I am getting quite a few segfaults when testing against 4.3.1.
Desktop/sage-4.3.1/sage -t devel/sage/sage/calculus/calculus.py devel/sage/sage/functions/piecewise.py devel/sage/sage/plot/plot.py devel/sage/sage/symbolic/expression.pyx devel/sage/sage/misc/functional.py devel/sage/sage/symbolic/relation.py devel/sage/sage/symbolic/assumptions.py devel/sage/sage/calculus/wester.py devel/sage/sage/calculus/functional.py
all do. Probably I should not have applied all patches at once, but I was impatient :)
comment:12 Changed 11 years ago by
- Reviewers set to Karl-Dieter Crisman
Update: None of the previous errors happen in this symbolics queue until I hit this ticket, so they are definitely due to this one.
More comments:
- The original patch only causes the sage/functions/generalized.py doctest errors, not the other two. It did not appear with all patches up through ticket #6465.
- The original patch does NOT cause massive slowdown or segfaults in doctesting sage/calculus/calculus.py.
So perhaps the referee patch has changed something weird?
comment:13 Changed 11 years ago by
- Status changed from needs_review to needs_work
Followup:
Adding the referee patch causes a number of segfaults in things relating to assumptions. For example, the calculus/calculus.py doctest where it is assumed that abs(q)<1, and the one in calculus/wester.py where it is assumed that x>=y, y>=z, z>=x. It is not consistent whether the assumption itself or the thing using the assumption causes the hang. Is it possible that the _is_* methods or the info flags in ginac/decl.pxi are responsible? This is a question out of ignorance; I don't see how they would interfere with Maxima or the use of it by (e.g.) symbolic_sum, but it's all I can think of.
Also, the citation.pyx and random_tests.py are repeatable.
comment:14 follow-up: ↓ 16 Changed 11 years ago by
I can't reproduce these problems on my 64-bit laptop with Sage 4.3.2.alpha0, gcc 4.3.4. I'll try on a 32-bit machine tomorrow.
Note that the rebased patch on #6961 applies without problems to a clean 4.3.2.alpha0 here. Though my patch queue contains trac_7822-py_log.take2.patch
before trac_6961-psi.rebased.patch
. I tested the rest of the queue when I rebased the patch for #6961, there weren't any problems.
Is it possible that the problems you report might be caused by the fact that your tree got messed up by the git style patches attached to #6465?
comment:15 Changed 11 years ago by
I cannot reproduce these problems on a 32-bit Debian Lenny box after applying all the symbolics patches and updating pynac to version 0.11.
comment:16 in reply to: ↑ 14 ; follow-up: ↓ 17 Changed 11 years ago by
Is it possible that the problems you report might be caused by the fact that your tree got messed up by the git style patches attached to #6465?
Possibly, but wouldn't that have made everything not work, as opposed to just a few weird segfaults related to assumptions and a couple other things?
Also, when I say I applied them all at once, what I mean is I applied them one after the other using hg_sage.import_patch, which I believe is equivalent to hg import.
comment:17 in reply to: ↑ 16 Changed 11 years ago by
- Status changed from needs_work to needs_review
I tried once more with the patches downloaded from trac. I cannot reproduce any problems.
Here is an easier way to test all the patches:
- Make a fresh clone, called "pynac"
- go to the source tree for the clone
cd $SAGE_ROOT/devel/sage-pynac
- download this tar file
wget http://boxen.math.washington.edu/home/burcin/pynac/pynac_patches.tar.bz2
- extract it to the queue repository
cd .hg tar jxvf ../pynac_patches.tar.bz2 cd ..
- apply all the patches
hg qpush -a
- if the new pynac package is not already installed download and install it
http://boxen.math.washington.edu/home/burcin/pynac/pynac-0.1.11.spkg
- rebuild Sage
./sage -br
- run tests
./sage -tp 3 devel/sage-pynac/sage/{symbolic,calculus,functions}
comment:18 Changed 11 years ago by
- Reviewers changed from Karl-Dieter Crisman to Karl-Dieter Crisman, Ross Kyprianou
applying trac_7822-py_log.take2.patch applying trac_6961-psi.rebased.patch applying trac_7876-pynac_print.take2.patch applying trac_7363-mul_coeff.patch applying trac_7955-integrate_latex.patch applying trac_7957-pynac_exceptions.patch applying trac_7916-same_name_method.take2.patch applying trac_6465-chain_rule.take2.patch applying trac_6465-moves-integration-into-sfunction-subclass.take2.patch patching file sage/misc/functional.py Hunk #1 FAILED at 662 1 out of 2 hunks FAILED -- saving rejects to file sage/misc/functional.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_6465-moves-integration-into-sfunction-subclass.take2.patch
comment:19 Changed 11 years ago by
See comment:19:ticket:6465. Two patches on that ticket needed to be rebased to 4.3.2. Unfortunately, I didn't have time to update the patch tarball.
You can use hg qdelete <patch_name>
to remove the offending patches from the queue, and hg qimport
new ones. The specific list of command to be executed is:
cd $SAGE_ROOT/devel/sage-pynac hg qpop -a hg qdelete trac_6465-moves-integration-into-sfunction-subclass.take2.patch hg qdelete trac_6465-integral.take3.patch hg qgoto trac_6465-chain_rule.take2.patch hg qimport http://trac.sagemath.org/sage_trac/raw-attachment/ticket/6465/trac_6465-integral.take4.patch hg qimport http://trac.sagemath.org/sage_trac/raw-attachment/ticket/6465/trac_6465-moves-integration-into-sfunction-subclass.take3.patch hg qpush -a
Then rebuild sage, and proceed with the tests...
Many thanks for looking at this.
comment:20 Changed 11 years ago by
The hg qgoto didnt work. (And if its easier at any stage to blow away the pynac clone and start again, feel free to suggest that).
rossk@sage:/scratch/rossk/sage-4.3.3.alpha0-sage.math.washington.edu-x86_64-Linux/devel/sage-pynac$ hg qgoto trac_6465-chain_rule.take2.patch applying trac_7822-py_log.take2.patch applying trac_6961-psi.rebased.patch applying trac_7876-pynac_print.take2.patch applying trac_7363-mul_coeff.patch applying trac_7955-integrate_latex.patch patching file sage/calculus/calculus.py Hunk #1 FAILED at 1710 Hunk #2 FAILED at 1719 Hunk #3 FAILED at 1742 Hunk #4 FAILED at 1771 Hunk #5 FAILED at 1781 Hunk #6 FAILED at 1790 6 out of 6 hunks FAILED -- saving rejects to file sage/calculus/calculus.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_7955-integrate_latex.patch
comment:21 Changed 11 years ago by
Hi Ross,
The last output you posted doesn't make sense to me. Did you update to 4.3.3.alpha0 since comment:18? In comment:18, the output shows that trac_7955-integrate_latex.patch
applies cleanly. I don't see any other reason why it would fail now.
I don't have a working copy of 4.3.3.alpha0 yet. Unfortunately, it will take me a couple of days update to that.
comment:22 Changed 11 years ago by
Youre right - made a minor mistake so I had to start again and I could only find a version of 4.3.3.alpha0 easily and I used that (apologies). To get some testing done sooner than later Ill go back to 4.3.3 for now. Thanks.
comment:23 Changed 11 years ago by
:) Ticket #7955 was merged in 4.3.3.alpha0, so it's natural that the patch fails. If you just do
hg qdelete trac_7955-integrate_latex.patch
the rest of the patches should apply without problems.
Thanks again for your time.
comment:24 Changed 11 years ago by
- Reviewers changed from Karl-Dieter Crisman, Ross Kyprianou to Karl-Dieter Crisman, Ross Kyprianou, Minh Van Nguyen
- Status changed from needs_review to positive_review
Looks good to me. See #6961 for the order in which to merge patches.
comment:25 Changed 11 years ago by
- Merged in set to sage-4.3.3.alpha1
- Resolution set to fixed
- Status changed from positive_review to closed
Merged in this order:
#6802 is a duplicate of this ticket.