questions about types.

[adrian]

In the following code:
sage: x=CC['x'].gen()
sage: type(x)
<class
'sage.rings.polynomial.polynomial_element_generic.Polynomial_generic_dense_field'>
sage: f(x)=sin(x)
sage: type(x)
<class 'sage.calculus.calculus.SymbolicVariable'>

Is this intended?

[Robert Bradshaw]

Yes. Otherwise one would need to write var('x') before writing f(x) =
sin(x).

- Robert

[Jason Grout]

Wow, Sage will redefine symbols that are already existing to accommodate
what should be a dummy variable? This looks seriously wrong and looks
like it could really mess things up.

For example:

sage: f(sage) = sin(sage)
sage: type(sage)
<class 'sage.calculus.calculus.SymbolicVariable'>

sage: f(i) = i^2
sage: type(i)
<class 'sage.calculus.calculus.SymbolicVariable'>
sage: i^2
i^2

I would strongly prefer that this is wrapped so that a local symbolic
variable is used that is not tied to anything, or even just so that the
value of x is reset after the function is assigned. Are we using
sage.calculus.calculus.var in the code so that we don't inject into the
global namespace, just like the docstring of var says?

Jason

[Simon King]

Dear Jason,

On Dec 3, 7:54 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
> Wow, Sage will redefine symbols that are already existing to accommodate
> what should be a dummy variable? This looks seriously wrong and looks
> like it could really mess things up.

I don't think so. Admittedly I don't like that x is pre-defined, but
here it is something else.
There are Sage constructions which define various things in one line.
For example,
sage: R.<z>=QQ[]
both defines R *and* z (the latter of type Polynomial_rational_dense).

Similarly, doing
sage: R(z)=sin(z)
both defines R *and* z (the latter of type SymbolicVariable).

And note that even the notation is consistent: In both examples, you
have two things on the left side of the assignment (R and z) -- and
both things get a (new) assignment.
Yours,
Simon

[Jason Grout]

To be more clear, currently we have:

sage: preparse('f(x)=sin(x)')

'_=var("x");f=symbolic_expression(sin(x)).function(x)'

I would strongly prefer this to be

sage:
_=sage.calculus.calculus.var("y");f=symbolic_expression(sin(_)).function(_)
sage: f
y |--> sin(y)

(or instead of "_", use whatever you can for a temporary variable)

Is there something terrible that would happen in that case?

Jason

[Simon King]

PS:

sage: R.<z>=QQ[]
sage: type(R)
<class 'sage.rings.polynomial.polynomial_ring.PolynomialRing_field'>
sage: type(z)
<class
'sage.rings.polynomial.polynomial_element_generic.Polynomial_rational_dense'>
sage: R=sin(z)
sage: type(R)
<class 'sage.calculus.calculus.SymbolicComposition'>
sage: type(z)
<class
'sage.rings.polynomial.polynomial_element_generic.Polynomial_rational_dense'>
sage: R(z)=sin(z)
sage: type(R)
<class 'sage.calculus.calculus.CallableSymbolicExpression'>
sage: type(z)
<class 'sage.calculus.calculus.SymbolicVariable'>

That's all consistent! R respectively z get a new meaning if and only
if they appear on the left side of an assignment.
Cheers,
Simon

[Jason Grout]

Simon King wrote:
> Dear Jason,
>
> On Dec 3, 7:54 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
>> Wow, Sage will redefine symbols that are already existing to accommodate
>> what should be a dummy variable? This looks seriously wrong and looks
>> like it could really mess things up.
>
> I don't think so. Admittedly I don't like that x is pre-defined, but
> here it is something else.
> There are Sage constructions which define various things in one line.
> For example,
> sage: R.<z>=QQ[]
> both defines R *and* z (the latter of type Polynomial_rational_dense).

In this case, z is not being used as a dummy variable. I think it makes
a lot of sense to define z globally when z is on the right, versus
defining z just locally when you have R = QQ['z']

>
> Similarly, doing
> sage: R(z)=sin(z)
> both defines R *and* z (the latter of type SymbolicVariable).

In this case, mathematical convention says that z is a dummy variable;
it should not matter what I call the thing inside the parentheses, and
it certainly shouldn't affect stuff outside of the function.

Maybe part of the huge difference in my mind is that R(z) = sin(z) tries
to follow a deeply-ingrained mathematical convention, while R.<z> is
defining new notation.

Jason

[Jason Grout]

Jason Grout wrote:
> Simon King wrote:
>> Dear Jason,
>>
>> On Dec 3, 7:54 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
>>> Wow, Sage will redefine symbols that are already existing to accommodate
>>> what should be a dummy variable? This looks seriously wrong and looks
>>> like it could really mess things up.
>> I don't think so. Admittedly I don't like that x is pre-defined, but
>> here it is something else.

This is getting off-topic (I'm the one to blame), so I'll take it over
to sage-devel, where it probably belongs anyway.

Jason