Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SR('I') is not consistent #25178

Open
videlec opened this issue Apr 16, 2018 · 14 comments
Open

SR('I') is not consistent #25178

videlec opened this issue Apr 16, 2018 · 14 comments

Comments

@videlec
Copy link
Contributor

videlec commented Apr 16, 2018

This behavior is confusing

sage: SR('I') ** 2   # complex imaginary
-1
sage: SR.var('I')
I
sage: SR('I') ** 2   # now a variable!
I^2

So far different solutions are under consideration

  1. Let SR('I') always return the imaginary unit (and use SR.var(string) to create variables)
  2. Add SR.I() as a method and let SR(string) always return a variable
  3. Create methods SR.e(), SR.I(), SR.pi() for named constants and let SR(string) always create variables.
  4. Forbid the names e, I, pi, etc as variable names.

CC: @rwst @slel @spaghettisalat

Component: symbolics

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

@videlec videlec added this to the sage-8.2 milestone Apr 16, 2018
@mo271
Copy link
Contributor

mo271 commented Apr 16, 2018

comment:1

I am not sure if this is really so bad. It is the same for other constants:

sage: SR('e').n()   # Euler's constant
2.71828182845905
sage: SR.var('e')   
e
sage: SR('e').n()   # now a variable
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

TypeError: cannot evaluate symbolic expression numerically

But I can imagine that it would be very useful to use e sometimes as a symbolic variable (e.g. when using a, b, c and d before..)

@jdemeyer
Copy link

comment:2

I agree that this is not a bug. I is just a variable with a default value of sqrt(-1), but that value can be changed.

@videlec
Copy link
Contributor Author

videlec commented Apr 16, 2018

comment:3

My complaint is about the way SR(whatever) is interpreting its argument. When I do SR.var('my_name') I clearly want a new variable name. But the behavior of SR(whatever) depends on the variables created at a given time. It is easy to imagine

def f():
    a,b,c,d,e = SR.var('a,b,c,d,e')
    # now using the symbolic variables

m = f()
e = SR('e')  # this is not anymore exp(1)!!

@mo271
Copy link
Contributor

mo271 commented Apr 16, 2018

comment:4

What do you propose to do? What behavior do you want to have? Should SR.var('a,b,c,d,e') raise an error?

I think a line like a,b,c,d,e = SR.var('a,b,c,d,e') or `a,b,c,d,e = var('a,b,c,d,e')' is very natural. In fact:

sage: search_src("var\('a, b, c, d, e")
tensor/coordinate_patch.py:230:            sage: a, b, c, d, e = var('a, b, c, d, e')
tests/french_book/nonlinear_doctest.py:64:    sage: a, b, c, d, e, f, x = var('a, b, c, d, e, f, x')
matrix/special.py:3625:        sage: matrix.hankel(SR.var('a, b, c, d, e'))
matrix/special.py:3634:        sage: matrix.hankel(SR.var('a, b, c, d, e'), SR.var('f, g, h, i'))

@videlec
Copy link
Contributor Author

videlec commented Apr 16, 2018

comment:5
  • option 1: keep SR.var('e') (variable creation) and make SR('e') always return exp(1) for consistency
  • option 2: forbid standard variable names (e, pi, cos, etc)

@videlec videlec changed the title I should not be allowed as a symbolic variable name SR('I') is not consistent Apr 16, 2018
@sagetrac-tmonteil
Copy link
Mannequin

sagetrac-tmonteil mannequin commented Apr 16, 2018

comment:7

One option could be to have SR.I(), SR.e(), etc working the same way as the existing SR.pi(), and let SR(string) return/inject a symbolic variable.

@videlec

This comment has been minimized.

@slel
Copy link
Member

slel commented Apr 17, 2018

comment:9

I don't see how

sage: SR('I') ** 2   # complex imaginary
-1
sage: SR.var('I')
I
sage: SR('I') ** 2   # now a variable!
I^2

is any more confusing than

sage: exp(1)         # exponential
e
sage: exp = log
sage: exp(1)         # now logarithm!
0

@videlec
Copy link
Contributor Author

videlec commented Apr 17, 2018

comment:10

Replying to @slel:

I don't see how

sage: SR('I') ** 2   # complex imaginary
-1
sage: SR.var('I')
I
sage: SR('I') ** 2   # now a variable!
I^2

is any more confusing than

sage: exp(1)         # exponential
e
sage: exp = log
sage: exp(1)         # now logarithm!
0

See [comment:3].

@videlec
Copy link
Contributor Author

videlec commented Apr 17, 2018

comment:11

More precisely

def f():
    exp = log
    SR.var('e')
f()
exp(x)  # still exp(x)
SR('e') # e is a variable here

@slel
Copy link
Member

slel commented Apr 17, 2018

comment:12

I get it now. The changed behaviour would be expected after

sage: I = SR.var('I')

but not after

sage: SR.var('I')

@videlec
Copy link
Contributor Author

videlec commented May 12, 2018

comment:13

Replying to @sagetrac-tmonteil:

One option could be to have SR.I(), SR.e(), etc working the same way as the existing SR.pi(), and let SR(string) return/inject a symbolic variable.

Indeed.

@videlec

This comment has been minimized.

@videlec videlec modified the milestones: sage-8.2, sage-8.3 May 12, 2018
@videlec
Copy link
Contributor Author

videlec commented Aug 3, 2018

comment:14

update milestone 8.3 -> 8.4

@videlec videlec modified the milestones: sage-8.3, sage-8.4 Aug 3, 2018
@mkoeppe mkoeppe modified the milestones: sage-8.4, sage-9.4 Jul 6, 2021
@mkoeppe mkoeppe modified the milestones: sage-9.4, sage-9.5 Aug 22, 2021
@mkoeppe mkoeppe modified the milestones: sage-9.5, sage-9.6 Dec 18, 2021
@mkoeppe mkoeppe removed this from the sage-9.6 milestone May 3, 2022
@mkoeppe mkoeppe added this to the sage-9.7 milestone May 3, 2022
@mkoeppe mkoeppe modified the milestones: sage-9.7, sage-9.8 Sep 19, 2022
@mkoeppe mkoeppe removed this from the sage-9.8 milestone Jan 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants