Status: Valid
Owner:
Labels: Type-Defect Priority-Medium Geometry
New issue 3253 by julien.r...@gmail.com: Test failure in geometry
http://code.google.com/p/sympy/issues/detail?id=3253
There's a test failure in master with this specific random seed: 95778648
It occurs with 32- and 64-bit
Updates:
Labels: -Priority-Medium Priority-Critical
Comment #1 on issue 3253 by asmeu...@gmail.com: Test failure in geometry
http://code.google.com/p/sympy/issues/detail?id=3253
(No comment was entered for this change.)
--
You received this message because you are subscribed to the
Comment #6 on issue 3249 by ness...@gmail.com: Difficulty with
integrate(exp(I*x)/(1 + x**2), (x, -oo, oo))
http://code.google.com/p/sympy/issues/detail?id=3249
Pull request: https://github.com/sympy/sympy/pull/1274
--
You received this message because you are subscribed to the Google
Updates:
Status: Fixed
Comment #4 on issue 2664 by smi...@gmail.com: sign(x) should reduce to
x/abs(x) when x is known to not be 0
http://code.google.com/p/sympy/issues/detail?id=2664
Now,
conjugate(x).diff(x)
Derivative(conjugate(x), x)
sign(1 + I)
sign(1 + I)
_.doit()
Updates:
Owner: julien.r...@gmail.com
Cc: asmeu...@gmail.com
Comment #5 on issue 2664 by julien.r...@gmail.com: sign(x) should reduce to
x/abs(x) when x is known to not be 0
http://code.google.com/p/sympy/issues/detail?id=2664
One could have sign(1 + I) reduce automatically
Updates:
Status: Fixed
Comment #5 on issue 2662 by smi...@gmail.com: conjugate(x).diff(x) is wrong
http://code.google.com/p/sympy/issues/detail?id=2662
Now we have
conjugate(x).diff(x)
Derivative(conjugate(x), x)
which, though not the same as above, is not wrong. So I will close
I'm trying to wrap an expression into a lambda and notice that the dummy
variable of the lambda doesn't match with the variable of the expression.
Am I doing this right?
Here, the lambda's i is not the same as the i in the expression I send:
def f(fi):
... return lambda i: fi
...
f(i+1)(1)
i
On Tuesday, May 1, 2012 1:03:37 AM UTC+5:45, Aaron Meurer wrote:
Based on Chris's previous examples, it looks like you can just create
a numbered_symbols generator from the start and pass that in each
time. Because it is a generator, it will keep track of the symbols
count as long as you
I have a set of Mathematica functions that I would like to translate
to sympy. I see the parsing.mathematica method and wonder what the
community thinks of the task of generalizing it to handle the
conversion of Mathematica modules to sympy? As the parser stands now
it seems to handle the
I doubt that any automated translation will produce quality code. The
style of Mathematica code is much more functional than the object
oriented python style. What you get from automatic translation will
not be human-readable (it will be python but very obfuscated).
So I am very pessimistic.
This probably is doable, but we would need an actual parser in SymPy,
which is the difficult part. If we had that, adding rules for
Mathematica functions would ideally not be hard. See
https://github.com/sympy/sympy/wiki/parsing for some ideas on parsing.
More realistically, in
11 matches
Mail list logo