Real domain for symbolic variables #6559

golam-m-hossain · 2009-07-19T11:10:52Z

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.

Component: symbolics

Keywords: pynac

Author: Golam Mortuza Hossain, Burcin Erocal

Reviewer: Karl-Dieter Crisman, Ross Kyprianou, Minh Van Nguyen

Merged: sage-4.3.3.alpha1

Issue created by migration from https://trac.sagemath.org/ticket/6559

The text was updated successfully, but these errors were encountered:

sagetrac-mvngu · 2009-08-22T14:17:46Z

comment:1

#6802 is a duplicate of this ticket.

golam-m-hossain · 2009-09-05T21:29:20Z

Attachment: trac_6559-domain-and-latex_name-for-variable.patch.gz

golam-m-hossain · 2009-09-05T21:50:05Z

Author: Golam Mortuza Hossain

maxthemouse · 2009-11-19T17:54:48Z

comment:3

How does this relate to pynac 0.1.9 which is in Sage 4.2.1? ~ Adam

sagetrac-rossk · 2010-01-14T03:56:27Z

comment:4

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

sagetrac-mvngu · 2010-01-18T02:44:03Z

Work Issues: needs rebase

burcin · 2010-01-19T13:56:13Z

Attachment: trac_6559-domain-and-latex_name-for-variable.take2.3.patch.gz

rebased to 4.3.1.rc0

burcin · 2010-01-19T14:38:15Z

Changed keywords from none to pynac

burcin · 2010-01-19T14:38:15Z

Changed work issues from needs rebase to none

burcin · 2010-01-19T14:38:15Z

Changed author from Golam Mortuza Hossain to Golam Mortuza Hossain, Burcin Erocal

burcin · 2010-01-19T14:38:15Z

comment:7

Attachment: trac_6559-referee.patch.gz

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() and sage.symbolic.ring.is_ComplexVariable() functions. The first is same as SR.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.

burcin · 2010-01-20T04:11:21Z

comment:8

Attachment: trac_6559-referee.take2.patch.gz

New patches up, ready for review.

Apply only:

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).

jasongrout · 2010-01-21T01:44:14Z

comment:9

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.

kcrisman · 2010-01-27T19:21:20Z

comment:10

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.

kcrisman · 2010-01-27T20:10:50Z

comment:11

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 :)

kcrisman · 2010-01-28T21:12:06Z

Reviewer: Karl-Dieter Crisman

kcrisman · 2010-01-28T21:12:06Z

comment:12

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 Derivative D acts wrongly on symbolic integration #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?

kcrisman · 2010-01-29T03:05:03Z

comment:13

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.

burcin · 2010-01-31T21:32:32Z

comment:14

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?

burcin · 2010-02-03T11:59:47Z

comment:15

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.

kcrisman · 2010-02-04T03:27:05Z

comment:16

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.

burcin · 2010-02-04T09:25:12Z

comment:17

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}

sagetrac-rossk · 2010-02-13T05:34:36Z

Changed reviewer from Karl-Dieter Crisman to Karl-Dieter Crisman, Ross Kyprianou

sagetrac-rossk · 2010-02-13T05:34:36Z

comment:18

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

burcin · 2010-02-13T10:56:10Z

comment:19

See #6465 comment:19. 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 https://github.com/sagemath/sage-prod/files/10645418/trac_6465-integral.take4.patch.gz
hg qimport https://github.com/sagemath/sage-prod/files/10645419/trac_6465-moves-integration-into-sfunction-subclass.take3.patch.gz
hg qpush -a

Then rebuild sage, and proceed with the tests...

Many thanks for looking at this.

sagetrac-rossk · 2010-02-13T12:13:56Z

comment:20

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

burcin · 2010-02-13T13:26:42Z

comment:21

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.

sagetrac-rossk · 2010-02-13T13:44:29Z

comment:22

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.

burcin · 2010-02-15T00:55:11Z

comment:23

:) 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.

sagetrac-mvngu · 2010-02-18T21:31:03Z

comment:24

Looks good to me. See #6961 for the order in which to merge patches.

sagetrac-mvngu · 2010-02-18T21:31:03Z

Changed reviewer from Karl-Dieter Crisman, Ross Kyprianou to Karl-Dieter Crisman, Ross Kyprianou, Minh Van Nguyen

sagetrac-mvngu · 2010-02-18T21:53:42Z

Merged: sage-4.3.3.alpha1

sagetrac-mvngu · 2010-02-18T21:53:42Z

comment:25

Merged in this order:

golam-m-hossain added c: symbolics labels Jul 19, 2009

This comment has been minimized.

Sign in to view

sagetrac-rossk mannequin added s: needs work and removed s: needs review labels Jan 14, 2010

sagetrac-mvngu mannequin added this to the sage-4.3.1 milestone Jan 18, 2010

sagetrac-mvngu mannequin added s: needs review and removed s: needs work labels Jan 18, 2010

sagetrac-mvngu mannequin added s: needs work and removed s: needs review labels Jan 18, 2010

burcin added s: needs review and removed s: needs work labels Jan 20, 2010

kcrisman added s: needs work and removed s: needs review labels Jan 29, 2010

burcin added s: needs review and removed s: needs work labels Feb 4, 2010

sagetrac-mvngu mannequin added s: positive review and removed s: needs review labels Feb 18, 2010

sagetrac-mvngu mannequin removed the s: positive review label Feb 18, 2010

sagetrac-mvngu mannequin closed this as completed Feb 18, 2010

kcrisman mentioned this issue Sep 21, 2009

var('x',ns=False) -- should go boom but silently gives a new symbolic variable #6340

Closed

sagetrac-schymans mannequin mentioned this issue Feb 19, 2010

Custom definitions for latex style #6403

Closed

sagetrac-mvngu mannequin mentioned this issue Feb 18, 2010

provide wrapper for psi function of GiNaC #6961

Closed

burcin mentioned this issue Jan 19, 2010

symbolic expression displayed wrong #7876

Closed

nathanncohen mannequin mentioned this issue Jan 14, 2023

Remove deprecated code from tickets <10000 #15568

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Real domain for symbolic variables #6559

Real domain for symbolic variables #6559

golam-m-hossain commented Jul 19, 2009

sagetrac-mvngu mannequin commented Aug 22, 2009

golam-m-hossain commented Sep 5, 2009

This comment has been minimized.

golam-m-hossain commented Sep 5, 2009

maxthemouse mannequin commented Nov 19, 2009

sagetrac-rossk mannequin commented Jan 14, 2010

sagetrac-mvngu mannequin commented Jan 18, 2010

burcin commented Jan 19, 2010

burcin commented Jan 19, 2010

burcin commented Jan 19, 2010

burcin commented Jan 19, 2010

burcin commented Jan 19, 2010

burcin commented Jan 20, 2010

jasongrout commented Jan 21, 2010

kcrisman commented Jan 27, 2010

kcrisman commented Jan 27, 2010

kcrisman commented Jan 28, 2010

kcrisman commented Jan 28, 2010

kcrisman commented Jan 29, 2010

burcin commented Jan 31, 2010

burcin commented Feb 3, 2010

kcrisman commented Feb 4, 2010

burcin commented Feb 4, 2010

sagetrac-rossk mannequin commented Feb 13, 2010

sagetrac-rossk mannequin commented Feb 13, 2010

burcin commented Feb 13, 2010

sagetrac-rossk mannequin commented Feb 13, 2010

burcin commented Feb 13, 2010

sagetrac-rossk mannequin commented Feb 13, 2010

burcin commented Feb 15, 2010

sagetrac-mvngu mannequin commented Feb 18, 2010

sagetrac-mvngu mannequin commented Feb 18, 2010

sagetrac-mvngu mannequin commented Feb 18, 2010

sagetrac-mvngu mannequin commented Feb 18, 2010

Real domain for symbolic variables #6559

Real domain for symbolic variables #6559

Comments

golam-m-hossain commented Jul 19, 2009

sagetrac-mvngu mannequin commented Aug 22, 2009

golam-m-hossain commented Sep 5, 2009

This comment has been minimized.

golam-m-hossain commented Sep 5, 2009

maxthemouse mannequin commented Nov 19, 2009

sagetrac-rossk mannequin commented Jan 14, 2010

sagetrac-mvngu mannequin commented Jan 18, 2010

burcin commented Jan 19, 2010

burcin commented Jan 19, 2010

burcin commented Jan 19, 2010

burcin commented Jan 19, 2010

burcin commented Jan 19, 2010

burcin commented Jan 20, 2010

jasongrout commented Jan 21, 2010

kcrisman commented Jan 27, 2010

kcrisman commented Jan 27, 2010

kcrisman commented Jan 28, 2010

kcrisman commented Jan 28, 2010

kcrisman commented Jan 29, 2010

burcin commented Jan 31, 2010

burcin commented Feb 3, 2010

kcrisman commented Feb 4, 2010

burcin commented Feb 4, 2010

sagetrac-rossk mannequin commented Feb 13, 2010

sagetrac-rossk mannequin commented Feb 13, 2010

burcin commented Feb 13, 2010

sagetrac-rossk mannequin commented Feb 13, 2010

burcin commented Feb 13, 2010

sagetrac-rossk mannequin commented Feb 13, 2010

burcin commented Feb 15, 2010

sagetrac-mvngu mannequin commented Feb 18, 2010

sagetrac-mvngu mannequin commented Feb 18, 2010

sagetrac-mvngu mannequin commented Feb 18, 2010

sagetrac-mvngu mannequin commented Feb 18, 2010