SymPy users can use sympy from different contexts or interfaces. They might use it through octave or sage or mathics etc. Or they can use SymPy directly in Python. The advantage of allowing users to use sympy directly in Python is that they can use all of the tools of the Python language to manipulate the expressions and they can easily "extend" sympy itself. The disadvantage is that we have no way to control the syntax.
The fact that 1j makes a complex literal in Python is a basic feature of the Python language and is listed on pretty much the first page of the tutorial for Python: https://docs.python.org/3/tutorial/introduction.html#numbers That's been a feature of Python for a long time and there is no way it's going to change. There is also no way for sympy to alter that behaviour. If we were to create an interface for users that had its own syntax and its own language etc then we would probably not bother with 1j. As long as users use sympy from within Python then it's just a fact of the language. I don't often see problems related to this in particular so I don't think it's that common. On Tue, 5 Jan 2021 at 11:48, David Bailey <d...@dbailey.co.uk> wrote: > > On 04/01/2021 23:05, Aaron Meurer wrote: > > On Mon, Jan 4, 2021 at 3:32 PM David Bailey <d...@dbailey.co.uk> wrote: > > There's always the risk that a syntax mistake will actually be valid > > syntax in some unrelated way. For example, you might accidentally > write x(y + z) instead of x*(y + z). x(y + z) is valid syntax (it > calls x as a function with the argument y + z). SymPy is actually able > to protect against this mistake because variables are not callable, > giving an error. But if the accidental thing is both syntactically and > semantically valid there's nothing SymPy can do. > > Well, since x could be either a function or a variable, but not both (I > think), you can't go from a valid expression to something else, merely by > leaving out the asterisk. > > However, in this case leaving out the asterisk transforms 4*j into > 4*sqrt(-1), which in the context of a long calculation involving j and > complex numbers, might be really hard to detect. I suppose the problem is > that 'j' is a popular choice of algebraic variable. > > I doubt it's possible > to make a programming language that avoids these ambiguities and > simultaneously lets you write mathematical expressions in a natural > way. Even raw mathematical notation itself has such ambiguities. In > basic chalkboard notation, whether x(y + z) means x of y + z or x > times y + z is context dependent on what x is, and generally depends > on implicit understanding of types and variable naming conventions. > > I wonder if there is a way to turn off the 'j' feature in Python. It really > does seem to be something of a hack (in Python, not SymPy) - here is what I > got without importing sympy > > It's not really a hack. The fact that 1x is normally a syntax error in > Python allows it to use this for special syntax without ambiguity. > > Isn't that almost the definition of a hack? > > This is also used for things like 1e2 or 0b101. In Python 2, there was > also the 1L syntax for long integers, but that was removed in Python > 3. The j or e or b in numeric literals have nothing to do with the > variables j, e, or b, if they even happen to be defined. It's similar > to the string prefix syntax in Python. You can write b"this is a byte > string", r"\sin(x)", or f"The value of x is: {x}". The b, r, and f > there are special syntax when placed before a string, and have nothing > to do with variables named b, r, or f. > > Well, I'd bet that a fair proportion of SymPy users are unaware that 'j' has > a special feature like this, that they should be aware of (I certainly was!). > Python obviously inherited many of those other notations you mention from C, > and clearly the notation <integer>L is just as dangerous as <integer>j. I > imagine removing the syntax '1L' from Python 3 caused a certain amount of > angst because it would break existing code, I suppose others disliked it > because it could be a source of mistakes. Since you obviously cannot break > existing code, I think it would be nice to provide a switch that users could > use to make all those notations illegal, as Jonathon has just suggested. > > Strings don't normally feature in algebra, so I'd have thought Python string > prefixes aren't so dangerous. > > Maybe I am over-reacting - I don't know. > > David > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/a75b9986-b907-f44f-0743-575cf62cedc2%40dbailey.co.uk. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxTeBX-_qGnOeJ4ctVcQUaTyxbuN7t5nfO2jgx5_udgwwA%40mail.gmail.com.
