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 sympyIt'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.
