I believe a solution would be to plug into the preparser and override the behavior. All I know is that the preparser provides a way to do this.
Jonathan On Monday, January 4, 2021 at 5:05:23 PM UTC-6 [email protected] wrote: > On Mon, Jan 4, 2021 at 3:32 PM David Bailey <[email protected]> wrote: > > > > On 04/01/2021 21:30, Thomas Ligon wrote: > > > > Hello David, > > indeed, when I enter print(sqrt(-1)), I get I, just as you do. > > However, when I enter print(4s**2), it is flagged with an error > "unexpected token 's'", so I immediately see that I have something wrong. > But, when I enter print(4j**2), I get (-16 + 0j), so python is just making > a complex number out of it, and so I overlooked the error. > > > > Right - I find that rather scary - just accidentally reverting to normal > algebraic notation - means you don't get an error message, but just a wrong > answer - only if you happen to use j in the calculation! I had always > assumed that assigning a variable to a symbol concealed python's native > processing (roughly speaking). > > 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. 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. > 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. Putting a variable right before > a string like x"" is normally a syntax error, so there's no ambiguity > there. > > I agree that it's confusing that the j in 1j is unrelated to the > variable j, but if you just remember that <number><letter> isn't > actually allowed in Python without some operator between the number > and letter (variable names cannot start with a number, and there's no > implicit multiplication), you won't run into trouble. > > If you *really* wanted to, you could write a processor for parse_expr > that failed on complex number literals. That would require passing a > string input. > > Aaron Meurer > > > > > >>> 4j > > 4j > > >>> j=0 > > >>> 4j**2 > > (-16+0j) > > >>> j**2 > > 0 > > >>> 1j**2 > > (-1+0j) > > > > 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 [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/0e10ee24-8a28-4ca8-0ae9-800232191d15%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/1da8c770-1cf3-4ca6-b149-6fe628b60d20n%40googlegroups.com.
