Re: [sympy] Problem with sqrt(-1)
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 wrote:
>
> On 04/01/2021 23:05, Aaron Meurer wrote:
>
> On Mon, Jan 4, 2021 at 3:32 PM David Bailey 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 L is just as dangerous as 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
Re: [sympy] Problem with sqrt(-1)
On 04/01/2021 23:05, Aaron Meurer wrote:
On Mon, Jan 4, 2021 at 3:32 PM David Bailey 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 L is
just as dangerous as 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.
Re: [sympy] Problem with sqrt(-1)
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 asme...@gmail.com wrote:
> On Mon, Jan 4, 2021 at 3:32 PM David Bailey 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 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 sympy+un...@googlegroups.com.
> > 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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/1da8c770-1cf3-4ca6-b149-6fe628b60d20n%40googlegroups.com.
Re: [sympy] Problem with sqrt(-1)
On Mon, Jan 4, 2021 at 3:32 PM David Bailey 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 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 sympy+unsubscr...@googlegroups.com.
> 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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BzX0pzJrdPxfhKPe_7%2BPxdctRf3tt2aEFK6VZBK7hXLQ%40mail.gmail.com.
Re: [sympy] Problem with sqrt(-1)
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). 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 -- 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/0e10ee24-8a28-4ca8-0ae9-800232191d15%40dbailey.co.uk.
Re: [sympy] Problem with sqrt(-1)
To be clear, only j where there is nothing between the number and "j" produces a complex number in Python, like 1j. j by itself is a normal variable name which isn't defined to anything by default (and x for any other letter x is a syntax error without a mathematical operation between the number and x). So as long as you remember that Python requires explicit multiplication, it's not a big deal to use j as a variable name unrelated to complex numbers. And indeed, it's quite common to use both i and j in Python programs for index variables in for loops. When using SymPy, it's better to use I for complex numbers because this can be used with exact numbers, like 2*I/3, which is the exact fraction 2/3 times sqrt(-1). Whereas Python complex literals are always floating point, so 2j/3 will produce the inexact quantity 0.j. And even something like 101j would be truncated to double precision. >>> 101j 1e+18j >>> 101*I 101*I Aaron Meurer On Mon, Jan 4, 2021 at 2:30 PM 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. > This means that both j and I mean sqrt(-1). > Just to add to the confusion, the mathematics paper I have been working on > was published in 1878 and the author used i and j as summation indices. But > then, someone else published an additional analysis in 1896 and avoided the > use of i as an index, using j and s instead, and saving i for sqrt(-1), and I > have been following that author's conventions. Now I think it would probably > be smart top avoid both i and j, or better, avoid i, I and j, because i is > used by mathematicians, I is used by sympy, and j is used by python and > electrical engineers. > > > On Monday, January 4, 2021 at 5:22:07 PM UTC+1 da...@dbailey.co.uk wrote: >> >> On 04/01/2021 10:37, Oscar Benjamin wrote: >> >> 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 > > -- > 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/292aef1f-be93-41dc-b011-90beff19b300n%40googlegroups.com. -- 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/CAKgW%3D6JQQNv5OtuBWzd70h%3DQWo0S%3DQk65tgA1z3XxUt06KHx5g%40mail.gmail.com.
Re: [sympy] Problem with sqrt(-1)
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. This means that both j and I mean sqrt(-1). Just to add to the confusion, the mathematics paper I have been working on was published in 1878 and the author used i and j as summation indices. But then, someone else published an additional analysis in 1896 and avoided the use of i as an index, using j and s instead, and saving i for sqrt(-1), and I have been following that author's conventions. Now I think it would probably be smart top avoid both i and j, or better, avoid i, I and j, because i is used by mathematicians, I is used by sympy, and j is used by python and electrical engineers. On Monday, January 4, 2021 at 5:22:07 PM UTC+1 da...@dbailey.co.uk wrote: > On 04/01/2021 10:37, Oscar Benjamin wrote: > > 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 > -- 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/292aef1f-be93-41dc-b011-90beff19b300n%40googlegroups.com.
Re: [sympy] Problem with sqrt(-1)
On 04/01/2021 10:37, Oscar Benjamin wrote: 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 -- 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/346382fd-f803-cac3-eb8c-767064402c68%40dbailey.co.uk.
Re: [sympy] Problem with sqrt(-1)
Thanks! So I made a stupid mistake, and forgot a *. I do that often, but
usually find the mistake fast.
Now I also found a remark in Stack Overflow:
Python adopted the convention used by electrical engineers. In that
field, i is used to represent current and use j as the square root of -1.
On Monday, January 4, 2021 at 11:38:17 AM UTC+1 Oscar wrote:
> In Python 4j is the literal syntax to create an imaginary number (0 +
> 4*I). You need to use 4*j.
>
> On Mon, 4 Jan 2021 at 10:10, Thomas Ligon wrote:
> >
> > My understanding is that Sympy uses I as sqrt(-1), but I am running into
> a problem with j. I have defined j as a symbol, but j**2 is sometimes
> returning -1.
> > Here is the code:
> >
> > from sympy import latex
> > from sympy import symbols, sqrt
> > m = symbols('m')
> > j = symbols('j')
> > s = symbols('s')
> > print(sqrt(-1))
> > print(latex(sqrt(-1)))
> >
> print(latex(-((s)/(j))*(4*(j-1)*s+4*j**2+4*j-2-4*(s-j+1)*m+m**2)/(2*(4j**2-1)-4*m+m**2)))
> > # print gives:
> > # - \frac{s \left(4 j^{2} + 4 j + m^{2} - m \left(- 4 j + 4 s + 4\right)
> + s \left(4 j - 4\right) - 2\right)}{j \left(m^{2} - 4 m - 34.0\right)}
> > # in other words, all "j" are symbols except that j**2 == -1
> >
> >
> > --
> > 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+un...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/50ead3a4-846a-4b6d-979c-2605d4cbc992n%40googlegroups.com
> .
>
--
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/6f46e1da-6af6-45c3-8504-386b4bfce81en%40googlegroups.com.
Re: [sympy] Problem with sqrt(-1)
In Python 4j is the literal syntax to create an imaginary number (0 +
4*I). You need to use 4*j.
On Mon, 4 Jan 2021 at 10:10, Thomas Ligon wrote:
>
> My understanding is that Sympy uses I as sqrt(-1), but I am running into a
> problem with j. I have defined j as a symbol, but j**2 is sometimes returning
> -1.
> Here is the code:
>
> from sympy import latex
> from sympy import symbols, sqrt
> m = symbols('m')
> j = symbols('j')
> s = symbols('s')
> print(sqrt(-1))
> print(latex(sqrt(-1)))
> print(latex(-((s)/(j))*(4*(j-1)*s+4*j**2+4*j-2-4*(s-j+1)*m+m**2)/(2*(4j**2-1)-4*m+m**2)))
> # print gives:
> # - \frac{s \left(4 j^{2} + 4 j + m^{2} - m \left(- 4 j + 4 s + 4\right) + s
> \left(4 j - 4\right) - 2\right)}{j \left(m^{2} - 4 m - 34.0\right)}
> # in other words, all "j" are symbols except that j**2 == -1
>
>
> --
> 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/50ead3a4-846a-4b6d-979c-2605d4cbc992n%40googlegroups.com.
--
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/CAHVvXxTge5AJLh3DR_8rogAOCMN7ZmrsgQi8uHDKbo0nd_CKOw%40mail.gmail.com.
