can't reproduce failure

[smichr]

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 a 64 vs 32-bit things?

/c

[smichr]

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 a 64 vs 32-bit things?

Sorry...the report is at http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sY-cYfDA

 

[Aaron Meurer]

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 2**31, I'm not sure), but on 64-bit computers,
it's 2**64 (or 2**63).

That test report says 64-bit, so you need to make sure you are using that again.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/sympy/-/rwKG_gqo6kgJ.
>
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.

[Chris Smith]

> 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

[Aaron Meurer]

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.flatten (and hence the sorting done there).
Clearly no method should be allowed to do that.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.

[Chris Smith]

I just changed the sorting of the hashable content in my rand branch.
Can you try to see if it works now?

[Aaron Meurer]

Nope. Same test failure. Same reason.

Aaron Meurer

On Fri, Jul 13, 2012 at 10:54 PM, Chris Smith <smi...@gmail.com> wrote:
> I just changed the sorting of the hashable content in my rand branch.
> Can you try to see if it works now?
>

[Chris Smith]

On Sat, Jul 14, 2012 at 12:04 AM, Aaron Meurer <asme...@gmail.com> 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 that I
think will make the test pass. (If dummies aren't used then the two
would be equal *except* for the dummies introduced by cse which causes
the new ordering of the terms.)

I also got 2.7.3 installed and found that cse tests are prone to
failure unless the preordertraversal uses sorting. Nothing had failed
before so I didn't include it, but now in running the tests on cse
several times I see that it does fail occasionally, so I now use the
key option for the preordertraversal.

I've opened a new pull request.

/c

[Aaron Meurer]

Tests now pass in your branch with that seed.

Aaron Meurer

[Aaron Meurer]

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