On Sun, 2021-03-14 at 04:42 -0700, Diego Sejas wrote:
> 2.If one defined "var('foo')", then overwrites it with "foo = 2", and for
> some reason needs the symbol "foo" again, is there any meaningful advantage
> in retrieving it from the cache "SR.symbols" instead of redefining it again?
I think the answers to all of the other questions hinge on this one,
and personally, I don't know. I'm tempted to say "for speed" but I
really doubt that it is faster unless you're creating new symbols in a
tight loop (why?).
The backend for our symbolics however is written in C. Unlike in
Python, it's common for a C library to say something like "it is an
error to call this function twice with the same symbol name," and you
are expected to Just Not Do That. Storing the existing symbols in a
dictionary may therefore be a way to keep the underlying C library
happy and consistent.
>
> 4. The every day user is not aware of the "SR.symbols" dictionary and the
> retrieving of previously defined symbols....For example, consider the
> following
> workflow:
>
> foo = SR.var('foo', domain='real')
> # Do something meaningful with "foo".
> # Do some other things not related to "foo".
> # At this point, you forgot that "foo" exists, and now you
> need a symbol with complex domain.
> foo = SR.var('foo')
>
> After this code is executed, I would wrongly assume "foo" is complex.
> However, since it was retrieved from the cache "SR.symbols", it still has
> real domain. For the sake of illustration, if after this code you execute
> "solve(foo^2==-1)", you get "[ ]".
>
We have nothing but bad choices here. Here's another example:
sage: x = SR.var('x', domain='complex')
sage: f = sqrt(x)
sage: x = SR.var('x', domain='real')
If you now expect the underlying symbol object to change its domain,
then you've covertly changed the meaning of "f". Or if you expect to
get back a new, real symbol named x... then you've got two symbols
alive with the same name that live in different spaces.
Some of these options may not be possible given the constraints imposed
by the underlying C library, but what I'm trying to say is, be careful
what you wish for!
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/3027b946420c1c9c0a46494ac5db8b81fe0f4b49.camel%40orlitzky.com.