Symbolic Variables for Internal Use

[Michael Jung]

I'd like to use symbolic expressions in the source code to compute taylor expansions of predefined functions. But this affects the use of variables named the same way on the level of the user. Is there a safe way to use the framework of symbolic calculus without affecting the variables globally?


Thanks in advance! :)

[Nils Bruin]

Short answer: no.

Workaround: conceive some prefix to make a really unlikely name; something like _my_internal_symbol_t_ or so.

Ameliorating circumstance: for the most part, symbolic variables are just immutable place-holders, so it shouldn't matter who uses them. Probably the most serious case is when your code interacts with user-supplied symbolic expressions and you need to ensure that the variable you use is distinct from the ones that occur in the supplied expressions. A prefix should handle that (this is also how sage tries to avoid collisions when shipping symbols to maxima: it prefixes them with _sage_var_). There is some global state in the form of assumptions that can affect the meaning of symbols in SR.

If you need multiple "unique" expressions you could go with a symbol generating function. A very primitive one:

def gensym_generator():
    i=1
    while True:
        yield SR.symbol("gensym%o"%i)
        i+=1
gensym=gensym_generator().next

Every time you call gensym() you'll get a new symbol. Beware that these symbols are not unique across sessions, so if you intend to use parallel processing you already need to do something else (hash time in milliseconds plus process ID together or something like that)

Also: don't overuse that kind of thing: symbolic variable are leaky (they don't really get garbage collected).

[Thierry]

Hi,

Indeed, we have:

sage: a = 2
sage: a
2
sage: b = var('a')
sage: b
a
sage: a
a

because the `var` function do two things simultaneously:
- return the symbol a
- let the Python name a point to the symbol a

The trick is to use SR.var instead, that only returns something but does
not play with the namespace:

sage: a = 2
sage: a
2
sage: b = SR.var('a')
sage: b
a
sage: a
2

Let me take the opportunity to promote the use of
https://ask.sagemath.org/questions/ for such questions, since it
benefits to more users (in particular it is well indexed by search
engines).

Ciao,
Thierry


>
> Thanks in advance! :)
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/dd3f5b1f-b9c4-437b-bcc1-809720da8d1b%40googlegroups.com.

[Michael Jung]

The issue is more subtle than that. My variable must be defined on the complex domain. But

sage: x = SR.var('x', domain='complex')

changes the domain of x permanently.

[Thierry]

OK, i did not understood your question. This is because symbols have
unique representation, based only on their "name", not assumptions:

sage: x = SR.var('x', domain='complex')

sage: y = SR.var('x', domain='real')
sage: x is y
True

This is indeed unfortunate. I would say it is a bug, but fixing it would
require to refactor a lot of code in handling assumptions. The only
short-term workaround i see is to use different symbols.

Ciao,
Thierry

>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/10e761af-fe61-4d42-a86e-573c80e81505%40googlegroups.com.