>
> Or made the algorithm not depending on the order. Either way is fine,
> but it has to be robust.
In my case the use of the set instead of a list helped to identify the
problem, so in this sense it was a good thing. This is why randomizing
testing order is also good.
So I understand your poin
On Sat, Nov 13, 2010 at 11:05 AM, Aaron S. Meurer wrote:
> This is exactly the same thing that I mentioned before. Iterating through a
> set has absolutely no guaranteed order, even if you do it two times with the
> same set in the same session. This is not even the same as something
> produc
This is exactly the same thing that I mentioned before. Iterating through a
set has absolutely no guaranteed order, even if you do it two times with the
same set in the same session. This is not even the same as something producing
different results on different machines; that sort of thing is
On 13 Nov., 11:08, smichr wrote:
> OK, the problem was a logical error in solve_linear that only showed
> up because it of the order terms were being processed in an
> expression. Since dummy variables were being used, sometimes the x
> would get processed before the y in something like x + y + sq
OK, the problem was a logical error in solve_linear that only showed
up because it of the order terms were being processed in an
expression. Since dummy variables were being used, sometimes the x
would get processed before the y in something like x + y + sqrt(x) and
sometimes the y would get proces
OK, I see in solve_linear that sometimes the set from which symbols
are picked is in order x, y and other times y, x. And one of those
fails and the other doesn't. So I think this means it's a hashing
issue that directs the branches traversed. Now I have to figure out
why it fails on the one branch
On Fri, Nov 12, 2010 at 4:50 PM, smichr wrote:
> I'm not sure how to disable to cache. But clearing it doesn't seem to
> help. I've reduced my test file down to a single loop over the single
> failing function and sometimes it works and sometimes it doesn't. Here
> is the test driving loop and res
I'm not sure how to disable to cache. But clearing it doesn't seem to
help. I've reduced my test file down to a single loop over the single
failing function and sometimes it works and sometimes it doesn't. Here
is the test driving loop and results. Look how sporadic they are:
from sympy.core.cach
I have to guesses:
1. hashing (like Aaron already mentioned)
2. caching
Both are related and responsible for inconsistent results of sympy.
Did you try to disable the cache to see if the test passes then?
Also, IIRC some tests fail if not executed in correct order (this is
bad and why I implemen
