Ah, I didn't notice that you had changed the test.
I don't understand how cse is reordering the terms. If you do "assert
expr.args[0] == ans.args[1]" and "assert expr.args[1] == ans.args[0]",
those both pass. Somehow, cse is bypassing Add.flatten.
Aaron Meurer
On Sat, Jul 14, 2012 at 12:18 AM,
Tests now pass in your branch with that seed.
Aaron Meurer
On Fri, Jul 13, 2012 at 11:54 PM, Chris Smith wrote:
> On Sat, Jul 14, 2012 at 12:04 AM, Aaron Meurer wrote:
>> Nope. Same test failure. Same reason.
>>
>
> OK, I think I understand the problem: each Subs instance creates its
> own du
On Sat, Jul 14, 2012 at 12:04 AM, Aaron Meurer wrote:
> Nope. Same test failure. Same reason.
>
OK, I think I understand the problem: each Subs instance creates its
own dummies; those cause the hash-ed args to sort differently so the
two sides of the equality aren't the same. I pushed something
Nope. Same test failure. Same reason.
Aaron Meurer
On Fri, Jul 13, 2012 at 10:54 PM, Chris Smith wrote:
> I just changed the sorting of the hashable content in my rand branch.
> Can you try to see if it works now?
>
> --
> You received this message because you are subscribed to the Google Grou
I just changed the sorting of the hashable content in my rand branch.
Can you try to see if it works now?
--
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 this group, send
I just checked it. It seems that that the order of the .args is
different for expr and Subs(f(_x, _y), (_x, _y), (0, x0)) + Subs(g(_x,
_y), (_x, _y), (0, x0)). The individual args are otherwise the same.
The only way I can see that happening is if expr is created by some
method that bypasses Add.f
> That test report says 64-bit, so you need to make sure you are using that
> again.
OK...no 64 bit here. And I really don't know how that particular test
can be failing.
stymied-in-32-bit-ly,
/c
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To p
If you were using 64 or 32 bit and are trying to use the other, that
will make a difference for the hash seed. The hash seed is the seed +
the architecture (32 or 64 bits). This is because hash values are
numbers that are one word, so on 32-bit computers, hash values can be
up to 2**32 (or maybe
On Friday, July 13, 2012 10:27:16 PM UTC-5, smichr wrote:
>
> Does anyone have an idea why, after setting the seed and hashseed, that I
> can't reproduce the failure under 2.7.3 in cse shown in this report:
> https://mail.google.com/mail/u/0/?shva=1#label/sympy/13882d26f36a1304
>
> Is it just
