1=2 produces a silent answer in sage notebook

[Pedro Cruz]

I was tring to remember if "simple" equality was "=" or "==".

The email is just to mention this:

#1/3 Sage command-line: (4.6)
sage: 1=2
(....)
TypeError: Must construct a function with a tuple (or list) of
symbolic variables.


#2/3 Sage notebook:
1=2
(returns nothing)

#3/3 Python command line:

>>> 1=2
File "<stdin>", line 1
SyntaxError: can't assign to literal


Pedro

[Ivan Andrus]

On Jan 22, 2011, at 1:04 PM, Pedro Cruz wrote:

> I was tring to remember if "simple" equality was "=" or "==".
>
> The email is just to mention this:
>
> #1/3 Sage command-line: (4.6)
> sage: 1=2
> (....)
> TypeError: Must construct a function with a tuple (or list) of
> symbolic variables.
>
>
> #2/3 Sage notebook:
> 1=2
> (returns nothing)

But if you try this in a single cell

1=2
1

it returns 2. This is because the preparser turns it into:

_sage_const_2 = Integer(2); _sage_const_1 = Integer(1)
_sage_const_1 =_sage_const_2
_sage_const_1

It would be nice if there we some way to make the _sage_const variables actually constant, but python has (to my knowledge) no way to do this. I'm not sure how easy it would be for the preparser to recognize this as an error and convert it to something with a nice error message.

Perhaps if all the constants were stored in a tuple then, since tuples are immutable, you couldn't assign to it. I have no expertise in this area though, so I don't know what other problems this may cause (probably many).

-Ivan

[Jason Grout]

On 1/22/11 8:06 AM, Ivan Andrus wrote:
> On Jan 22, 2011, at 1:04 PM, Pedro Cruz wrote:
>
>> I was tring to remember if "simple" equality was "=" or "==".
>>
>> The email is just to mention this:
>>
>> #1/3 Sage command-line: (4.6)
>> sage: 1=2
>> (....)
>> TypeError: Must construct a function with a tuple (or list) of
>> symbolic variables.
>>
>>
>> #2/3 Sage notebook:
>> 1=2
>> (returns nothing)
>
> But if you try this in a single cell
>
> 1=2
> 1
>
> it returns 2. This is because the preparser turns it into:
>
> _sage_const_2 = Integer(2); _sage_const_1 = Integer(1)
> _sage_const_1 =_sage_const_2
> _sage_const_1
>

On the command line:

sage: preparse('1=2')
'__tmp__=var("1"); Integer = symbolic_expression(Integer(2)).function(1)'

It looks like the problem is that it is treating this like f=x^2. Here
is another problem:

sage: var('1')
1

so I think there is definitely a problem with both var() and with the
preparser here.

Since Python doesn't allow identifiers to start with a number [1], we
shouldn't allow var() objects to start with a number.

I suppose someone could use this feature like this:

sage: one=var('1')
sage: one
1
sage: type(one)
<type 'sage.symbolic.expression.Expression'>

but I think that is too confusing to be a good thing.

-Jason

[1] http://docs.python.org/reference/lexical_analysis.html#identifiers

[Ivan Andrus]

On Jan 22, 2011, at 4:05 PM, Jason Grout wrote:
> On 1/22/11 8:06 AM, Ivan Andrus wrote:
>> On Jan 22, 2011, at 1:04 PM, Pedro Cruz wrote:
>>
>>> I was tring to remember if "simple" equality was "=" or "==".
>>>
>>> The email is just to mention this:
>>>
>>> #1/3 Sage command-line: (4.6)
>>> sage: 1=2
>>> (....)
>>> TypeError: Must construct a function with a tuple (or list) of
>>> symbolic variables.
>>>
>>>
>>> #2/3 Sage notebook:
>>> 1=2
>>> (returns nothing)
>>
>> But if you try this in a single cell
>>
>> 1=2
>> 1
>>
>> it returns 2. This is because the preparser turns it into:
>>
>> _sage_const_2 = Integer(2); _sage_const_1 = Integer(1)
>> _sage_const_1 =_sage_const_2
>> _sage_const_1
>>
>
> On the command line:
>
> sage: preparse('1=2')
> '__tmp__=var("1"); Integer = symbolic_expression(Integer(2)).function(1)'
>
> It looks like the problem is that it is treating this like f=x^2. Here is another problem:

So why the difference between the preparse function and preparsing a file? Is it because I'm using 4.6 instead of 4.6.1? or is it intentional? a bug?

> sage: var('1')
> 1
>
> so I think there is definitely a problem with both var() and with the preparser here.
>
> Since Python doesn't allow identifiers to start with a number [1], we shouldn't allow var() objects to start with a number.
>
> I suppose someone could use this feature like this:
>
> sage: one=var('1')
> sage: one
> 1
> sage: type(one)
> <type 'sage.symbolic.expression.Expression'>
>
> but I think that is too confusing to be a good thing.

Agreed.

> -Jason
>
>
> [1] http://docs.python.org/reference/lexical_analysis.html#identifiers