On Jul 16, 2010, at 4:00 AM, smichr wrote: > Hi all, > > I have a lot of work that I have separated out into about 35 issues. > The work deals with everything from minor editing of code, to handling > of non-commutatives in simplifications and (hopefully) a total purge > of power-rule infractions (e.g. allowing sqrt(x*y) to become > sqrt(x)*sqrt(y)). When all changes are made, the runtime of the test > suite drops by about 20%.[1] > > This work has survived through the new polys and the ploughing of the > core. If it's going to make it in I would really like to get some help > on reviewing these issues before any other major changes take place. > > ======== it's in branch t at smichr's' github > account =========== > > Everything is sitting in branch t at the smichr account at github. > Everything has been rebased on master. All tests and doctests passed > in 64 bit (but I am double checking after the rebase on the current > master). > > Although the first few commits are independent of each other the > commits that follow them become interdependent. I'm not sure what the > best way is to review these. I can' pull them off independently for > review since they won't rebase on master as independent; the term we > use on the issue page for such issues is "blocked on". The way I would > review these if they were on someone else's branch would be to use > gitk to view a single commit; if I wanted to confirm that the tests > passed I would checkout the particular commit and test it. > > So, > > 1) are there ideas of how best to review this? > 2) is there someone that has a fast 32-bit machine that would be > willing to run the tests to make sure that they run there? I am using > a script of Aaron's that makes this really easy: you just give the > starting and ending SHA for the commits and they are all tested and > the results sent to a file.
Actually, you don't have to have a 32-bit "machine" to have 32-bit Python. You can build 32-bit executables that run on x86-32 because x86-64 is fully backward compatible (see http://en.wikipedia.org/wiki/X86-64). I was able to compile 32-bit Python 2.6 on Ondrej's machine a while ago, and I think it is still there somewhere. I wasn't able to figure out the correct compiler flags for Python 2.5 or 2.4, and it was before Python 2.7. So you might try building Python in 32-bit. The flags that I used are here: http://wiki.sympy.org/wiki/Talk:Buildbot. See also http://asmeurersympy.wordpress.com/2009/11/13/how-to-get-both-32-bit/ for more info on this and how to test if your Python executable is 32-bit or 64-bit. Aaron Meurer > 3) is there someone who can profile this to identify any areas that > regressed significantly in terms of performance? > > [1] it's about 17% if the sympification of strings is done by default, > but that is something that can probably change with the converter- > option in sympify. This will no doubt come up in the review process. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sy...@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sy...@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
