Comment #42 on issue 1491 by vlada.pe...@gmail.com: Remove old printing
ordering at some point
http://code.google.com/p/sympy/issues/detail?id=1491
Hum, I just reread this and it occurs to me you only want to deprecate it
for 0.7.3, while I wanted to deprecate it now and remove it by 0.7.3
Updates:
Status: Fixed
Comment #11 on issue 935 by vlada.pe...@gmail.com: .match() behaves in a
random manner.
http://code.google.com/p/sympy/issues/detail?id=935
Is this still relevant? We now have a better (canonical) ordering on args
so this should be consistent everywhere. Compa
Updates:
Status: Fixed
Comment #9 on issue 940 by vlada.pe...@gmail.com: remove sympy/specfun
http://code.google.com/p/sympy/issues/detail?id=940
Right, except I forgot to actually mark it was "Fixed". Fixed the Fixed
now. :)
--
You received this message because you are subscribed to
Updates:
Status: Fixed
Comment #3 on issue 2541 by vlada.pe...@gmail.com: autowrap failing test
http://code.google.com/p/sympy/issues/detail?id=2541
This was Fixed by pull request 474. Marking as Fixed.
--
You received this message because you are subscribed to the Google Groups
"sympy
Updates:
Status: Fixed
Comment #11 on issue 313 by vlada.pe...@gmail.com: importing Plot in a fast
way
http://code.google.com/p/sympy/issues/detail?id=313
I'd say this is Fixed, plotting works, import is not (that) slow and Plot?
also works in iSymPy. Anyone disagree?
--
You recei
Updates:
Status: Invalid
Comment #1 on issue 969 by vlada.pe...@gmail.com: Add _sympycore_ method.
http://code.google.com/p/sympy/issues/detail?id=969
I think this is no longer relevant. sympycore is far, far away from being
merged in (if ever), though there was some recent activity on
Updates:
Status: Invalid
Comment #2 on issue 1396 by vlada.pe...@gmail.com: separate pyglet from
sympy, ship all in one package: SPD
http://code.google.com/p/sympy/issues/detail?id=1396
I'm not sure what SPD is but seems to be dead enough; besides, we've
already unbundled Pyglet. Cl
Comment #28 on issue 1924 by matt...@gmail.com: Eq() gets .as_basic() method
http://code.google.com/p/sympy/issues/detail?id=1924
As a side note, I'm curious why:
In [1]: Eq(FiniteSet(1, 2), FiniteSet(1, 2, 3))
Out[1]: {1, 2} = {1, 2, 3}
although:
In [2]: Eq(1, 2)
Out[2]: False
I think [1] s
Comment #29 on issue 1924 by smi...@gmail.com: Eq() gets .as_basic() method
http://code.google.com/p/sympy/issues/detail?id=1924
So there might be an _eval_Eq method, the default being to put the
objects in the lhs and rhs; for FiniteSet, the evaluation would be to
return True or False.
--
You
Updates:
Status: Fixed
Owner: ---
Comment #3 on issue 2586 by vlada.pe...@gmail.com: Use the numpy docstring
format for API docs
http://code.google.com/p/sympy/issues/detail?id=2586
Well, this got in! Marking as Fixed.
--
You received this message because you are subscribed t
Comment #30 on issue 1924 by asmeu...@gmail.com: Eq() gets .as_basic()
method
http://code.google.com/p/sympy/issues/detail?id=1924
As Ronan noted, the confusion here stems from issue 1887. We probably
should try to fix that first.
--
You received this message because you are subscribed t
Comment #12 on issue 935 by asmeu...@gmail.com: .match() behaves in a
random manner.
http://code.google.com/p/sympy/issues/detail?id=935
Actually, if I remember correctly, match can still be different because it
iterates over a dictionary. But the point is that if you don't want p and
q
12 matches
Mail list logo
