Re: Issue 2626 in sympy: Piecewise should use a different syntax for otherwise

2011-08-09 Thread sympy
Updates: Status: Started Comment #7 on issue 2626 by asmeurer: Piecewise should use a different syntax for otherwise http://code.google.com/p/sympy/issues/detail?id=2626 I've started to fix this in my piecewise-syntax branch. I'll submit it as a pull request when it's all ready.

Re: Issue 2626 in sympy: Piecewise should use a different syntax for otherwise

2011-08-09 Thread sympy
Updates: Cc: ness...@googlemail.com Comment #8 on issue 2626 by asmeurer: Piecewise should use a different syntax for otherwise http://code.google.com/p/sympy/issues/detail?id=2626 I need to implement Piecewise._eval_leading_term, which was previously relying on Function's method

Issue 2628 in sympy: Pretty pint RootSum

2011-08-09 Thread sympy
Status: Accepted Owner: asmeurer CC: matt...@gmail.com Labels: Type-Enhancement Priority-Medium Printing Polynomial New issue 2628 by asmeurer: Pretty pint RootSum http://code.google.com/p/sympy/issues/detail?id=2628 Maple prints its equivalent of RootSum objects as a summation. Here is an

Re: Issue 2628 in sympy: Pretty print RootSum

2011-08-09 Thread sympy
Updates: Summary: Pretty print RootSum Comment #1 on issue 2628 by asmeurer: Pretty print RootSum http://code.google.com/p/sympy/issues/detail?id=2628 That got messed up, probably because I had my terminal full screen and Maple centers the output. This should be more readable:

Re: Issue 2607 in sympy: as_numer_denom() is too slow

2011-08-09 Thread sympy
Comment #40 on issue 2607 by smi...@gmail.com: as_numer_denom() is too slow http://code.google.com/p/sympy/issues/detail?id=2607 OK, here's the current results of my work: I have two modifications in preprocessing: one where just the numerical lcm is computed and another where that and the

Re: Issue 2607 in sympy: as_numer_denom() is too slow

2011-08-09 Thread sympy
Comment #41 on issue 2607 by asmeurer: as_numer_denom() is too slow http://code.google.com/p/sympy/issues/detail?id=2607 So simple gcd is the most reliable in speed (at least your 1/Dummy()) test indicates that. I would try more advanced expressions, too, though. For example, try an

Re: Issue 2607 in sympy: as_numer_denom() is too slow

2011-08-09 Thread sympy
Comment #42 on issue 2607 by smi...@gmail.com: as_numer_denom() is too slow http://code.google.com/p/sympy/issues/detail?id=2607 I use expand=False with terms_gcd to keep things simple. And the 'simple gcd' I should have labelled as 'lcm': I give all terms the same leading coeff so

Re: Issue 2607 in sympy: as_numer_denom() is too slow

2011-08-09 Thread sympy
Comment #43 on issue 2607 by smi...@gmail.com: as_numer_denom() is too slow http://code.google.com/p/sympy/issues/detail?id=2607 I'm finding that there are too many special things to watch out for. The approach is sound, I think, but what is going to happen is that I am just going to end up

Re: Issue 2607 in sympy: as_numer_denom() is too slow

2011-08-09 Thread sympy
Comment #44 on issue 2607 by asmeurer: as_numer_denom() is too slow http://code.google.com/p/sympy/issues/detail?id=2607 What we need is a way to keep all the flatten info and then just update that info as terms are removed. Exactly. That's what issue 683 is all about, but it's going to