Status: Valid
Owner:
Labels: Type-Defect Priority-Low
New issue 3314 by unlimite...@gmail.com: sqrtdenest strongly depends on the
order of .args.
http://code.google.com/p/sympy/issues/detail?id=3314
In a number of places, the result of sqrtdenest differs depending on the
order in
Status: Valid
Owner:
Labels: Type-Defect Priority-Medium
New issue 3315 by unlimite...@gmail.com: In meijerint_definite, the result
depends on the order of points in innermost
http://code.google.com/p/sympy/issues/detail?id=3315
The problem occurs around
Status: Valid
Owner:
Labels: Type-Defect Priority-Low
New issue 3316 by unlimite...@gmail.com: Expr.expand: the result depends on
the order in which hints are traversed.
http://code.google.com/p/sympy/issues/detail?id=3316
Expr.expand invokes the corresponding _eval_expand_* methods
Status: Valid
Owner:
Labels: Type-Defect Priority-Medium Integration WrongResult
New issue 3317 by vinzent.steinb...@gmail.com: failing integral with abs()
http://code.google.com/p/sympy/issues/detail?id=3317
In [1]: var('t1:4')
Out[1]: (t₁, t₂, t₃)
In [2]: var('beta')
Out[2]: β
In [3]:
Updates:
Cc: mario.pe...@gmail.com smi...@gmail.com
Labels: Simplify
Comment #1 on issue 3314 by asmeu...@gmail.com: sqrtdenest strongly depends
on the order of .args.
http://code.google.com/p/sympy/issues/detail?id=3314
(No comment was entered for this change.)
--
You
This PR implements printing operations for Tr operators and partial trace
operations. Also cycle permutes are fixed for consistency. Some changes added
to Density class to enable partial trace operations. Also, new set of Notebook
examples have been provided.
You can merge this Pull Request by
On Sat, Jun 30, 2012 at 12:29 PM, Aaron Meurer asmeu...@gmail.com wrote:
As I noted on your pull request, I think a better way is to just wrap
the output in an unordered type (set or dict), and let either the
pretty printer or the doctest printer sort the output (both will do
so). That way, we
On Sat, Jun 30, 2012 at 12:14 AM, Joachim Durchholz j...@durchholz.org wrote:
Am 29.06.2012 23:24, schrieb Ondřej Čertík:
I think that there is a huge speed penalty for sorting the actual
arguments.
Why do you think so?
Because I tried it. We tried a lot of things when trying to make the
Am 01.07.2012 09:07, schrieb Ondřej Čertík:
Maybe you can figure out some way which is hash() independent and
still fast. At least I didn't figure it out.
I'd try something like this:
a) Yes, use native dicts as much as possible. Trying to improve over a
core data structure that's getting
+1 to this. Each function should know how to numerically evaluate
itself using numpy or stdlib math (or whatever), and you should be
able to just do it directly, like expr.evalf(library=numpy) or
something like that. I don't see any reason why that wouldn't work.
eval'ing strings feels like
Am 01.07.2012 10:58, schrieb krastanov.ste...@gmail.com:
It basically rebuilds the object tree using string manipulations over
the str(expression) output. It is a hack, like the old lambdify in
this regard (the code is documented in details however).
It could be prone to breakage.
It could be prone to breakage.
str(expression) might be changed by people who're not aware that lambdify
depends on things like parseability and adherence to naming conventions in
str().
A lambdify of whatever variant that traced the object tree directly would be
much preferrable over
If I understand correctly the commit logs and the blog posts of the
gsoc student that did this some years ago, sympy's evaluation to
floats is too slow in order to use for plotting. The solution was to
compile expressions to standard precision non-symbolic numpy or just
python.math. The horrifying
Hi,
There are opposite opinions about usage of decorator
in PR #1226.
In brief: decorator used as an arguments checker for __new__ method
(it's really helps to reduce the length of code).
Honestly the PR is stuck. If you have any
ideas to resolve this dispute. please write your comment.
Am Freitag, 29. Juni 2012 16:11:01 UTC+2 schrieb kjetil1001:
You are right, it should not be 0, this is a bug. Do you know the
correct
value?
Yes. This is a special case of the so-called Selberg integral (named
for Atle Selberg) , see
Am 01.07.2012 13:05, schrieb krastanov.ste...@gmail.com:
I suppose that this makes you, as a professional programmer, get a
headache over the fragile design :)
Hehe, sort of.
Not that I should be too critical of that, I have certainly written my
share of ugly code - mostly due to performance
Am 01.07.2012 15:19, schrieb krastanov.ste...@gmail.com:
Deprecating lambdify and refactoring everything to use a new library
keyword argument (or something similar) will be great though.
Sounds reasonable.
--
You received this message because you are subscribed to the Google Groups
sympy
On Jul 1, 2012, at 1:20 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
On Sat, Jun 30, 2012 at 7:48 PM, Aaron Meurer asmeu...@gmail.com wrote:
On Jun 30, 2012, at 8:38 PM, krastanov.ste...@gmail.com
krastanov.ste...@gmail.com wrote:
Two reasons basically:
- the original lambdify has a
On Sun, Jul 1, 2012 at 1:14 AM, Joachim Durchholz j...@durchholz.org wrote:
Am 01.07.2012 09:07, schrieb Ondřej Čertík:
Maybe you can figure out some way which is hash() independent and
still fast. At least I didn't figure it out.
I'd try something like this:
a) Yes, use native dicts as
On Sun, Jul 1, 2012 at 7:54 AM, Aaron Meurer asmeu...@gmail.com wrote:
On Jul 1, 2012, at 1:20 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
On Sat, Jun 30, 2012 at 7:48 PM, Aaron Meurer asmeu...@gmail.com wrote:
On Jun 30, 2012, at 8:38 PM, krastanov.ste...@gmail.com
The AST stuff may be interesting and amusing, however before any
actual benchmarking it seems like overly complicated solution.
.evalf() is slow not because it traverses the expression tree (any
evaluation method would do this, closures would not make less function
calls which is the expensive
It is mostly my fault that this is stuck. I said that simply using
default named arguments would be a better decision (see discussion on
the pull request page). However if someone else gives a +1 one on this
topic, the PR should be ok for merging.
I would like to implement what I proposed,
a) Yes, use native dicts as much as possible. Trying to improve over a core
data structure that's getting unlimited love from the language team doesn't
sound like a winning idea to me :-)
Yes, this is the main point in Python.
b) Keep the sorted list of keys in a separate member variable.
Some details at http://tinyurl.com/8y4h9ad
On the same topic, here is a future optional dependency for sympy:
http://anthon.home.xs4all.nl/Python/ordereddict/
An ordered dict module in C. (sorry, don't derail the discussion over
this, I am just leaving it for future reference)
--
You received
Slightly off topic, you have already merged contributions, however I
am not sure that you were added to the AUTHORS file.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from
Am 01.07.2012 21:56, schrieb Chris Smith:
a) Yes, use native dicts as much as possible. Trying to improve over a core
data structure that's getting unlimited love from the language team doesn't
sound like a winning idea to me :-)
Yes, this is the main point in Python.
b) Keep the sorted list
On Mon, Jul 2, 2012 at 12:38 AM, Joachim Durchholz j...@durchholz.org wrote:
Am 01.07.2012 21:56, schrieb Chris Smith:
a) Yes, use native dicts as much as possible. Trying to improve over a
core
data structure that's getting unlimited love from the language team
doesn't
sound like a winning
Am 01.07.2012 20:13, schrieb Ondřej Čertík:
This is at least my experience, but if you have time, please do try it out
in the sympyx code and compare the speed.
I'm a bit short on free time right now, so I may not be able to do
anything in the next few days.
That said, I'll try to find a few
On Jul 1, 2012, at 12:23 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
On Sun, Jul 1, 2012 at 7:54 AM, Aaron Meurer asmeu...@gmail.com wrote:
On Jul 1, 2012, at 1:20 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
On Sat, Jun 30, 2012 at 7:48 PM, Aaron Meurer asmeu...@gmail.com wrote:
On
You talked me into it =) I implement it simply with default argument
(and make another PR). If this implementation will be better,
it will be possible to abandon decorator.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To view this discussion on the
Yes, you're right. One of PR was merged yesterday.
On Sunday, July 1, 2012 11:57:04 PM UTC+3, Stefan Krastanov wrote:
Slightly off topic, you have already merged contributions, however I
am not sure that you were added to the AUTHORS file.
--
You received this message because you are
I did the following test. I applied the following patch:
diff --git a/sympy/core/add.py b/sympy/core/add.py
index d2cac9a..d5c3855 100644
--- a/sympy/core/add.py
+++ b/sympy/core/add.py
@@ -271,6 +271,9 @@ def as_coefficients_dict(a):
di.update(d)
return di
+def
Am 01.07.2012 20:13, schrieb Ondřej Čertík:
On Sun, Jul 1, 2012 at 1:14 AM, Joachim Durchholz j...@durchholz.org wrote:
b) Keep the sorted list of keys in a separate member variable.
c) Create the sorted key list lazily (i.e. only when it's actually needed).
I am afraid it is needed pretty
33 matches
Mail list logo
