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/CAKgW%3D6%2BzX0pzJrdPxfhKPe_7%2BPxdctRf3tt2aEFK6VZBK7hXLQ%40mail.gmail.com.
