In Python 4j is the literal syntax to create an imaginary number (0 + 4*I). You need to use 4*j.
I don't understand this because Thomas Lignon imported sqrt from sympy, so why didn't he get the imaginary answer he was expecting?
Indeed, trying this with Python 3.7 and SymPy 1.7, I get:
import sympy
from sympy import sqrt
sqrt(-1)
I
David
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).
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
>>> 4j
4j
>>> j=0
>>> 4j**2
(-16+0j)
>>> j**2
0
>>> 1j**2
(-1+0j)
David
On Mon, Jan 4, 2021 at 3:32 PM David Bailey <da...@dbailey.co.uk> wrote:There's always the risk that a syntax mistake will actually be validsyntax 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.
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