Re: [PATCH] initial fcode implementation

The patch looks fine to me, however I'm not familiar with fortran. But no one objected so far, so I pushed it in, thanks. Vinzent 2010/2/24 Toon Verstraelen : > --- >  doc/src/modules/printing.txt       |   96 +++ >  sympy/__init__.py                  |    2 +- >  sympy/printing/__init__.

Re: [PATCH] refine: Let refine_Pow work harder to simplify powers of (-1)

This is in, thank you! Vinzent 2010/2/23 Øyvind Jensen : > Before, 'refine_Pow' would simplify (-1)**exp only if 'exp' as a whole could > be determined as even or odd.  A doctest like, > >        >>> refine_Pow((-1)**(x+y), Assume(x, Q.even)) >        (-1)**y > > would fail.  This patch fixes tha

Re: [PATCH] Fix resolutor consistency check in ask()

Thank you, I pushed it in. Fabian, if you have any objections, we can make another patch. Vinzent 2010/2/23 Øyvind Jensen : > An exception could be raised as a false positive.  We should only > demand consistency between two resolutors if they have both reached a > conclusion.  Before this patch

Re: [PATCH] initial fcode implementation

Thanks alot! Vinzent Steinberg wrote: The patch looks fine to me, however I'm not familiar with fortran. But no one objected so far, so I pushed it in, thanks. Vinzent 2010/2/24 Toon Verstraelen : --- doc/src/modules/printing.txt | 96 +++ sympy/__init__.py |

Re: [PATCH 1/2] Implemented the Implies class to compile away in the same sense as Xor, Nand, etc. One of the tests led to misleading results ('Implies(False, False) == False' should not hold), and

What is the motivation of this? It would be nice if you could add this to the commit message. 'Implies(x, y)' is clearly less readable than 'Or(Not(x), y)', imho. Fabian, what is your opinion about this? Vinzent 2010/3/17 Christian Muise : > --- >  doc/src/modules/logic.txt         |    7 --

Re: [PATCH 2/2] Removing the option for passing in a list of pairs, since the outcome is ambiguous when two pairs are given as arguments.

2010/3/17 Christian Muise : > --- >  sympy/logic/boolalg.py |    6 ++ >  1 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/sympy/logic/boolalg.py b/sympy/logic/boolalg.py > index 0a45e42..97c47b7 100755 > --- a/sympy/logic/boolalg.py > +++ b/sympy/logic/boolalg.py > @@ -109,10 +

Re: [PATCH 1/2] Implemented the Implies class to compile away in the same sense as Xor, Nand, etc. One of the tests led to misleading results ('Implies(False, False) == False' should not hold), and

Looking at the implementation of Xor, Nand, Nor, and Not classes, it appears that the aim is to maintain formulas in negation normal form ( http://en.wikipedia.org/wiki/Negation_normal_form ). This would imply (excuse the pun ;)) that the Implies class should do the same. On Fri, Mar 19, 2010 at

Re: [PATCH 2/2] Removing the option for passing in a list of pairs, since the outcome is ambiguous when two pairs are given as arguments.

Not sure what such a test would look like...other oddities are left unhandled such as Not(). What's the policy for sympy on testing thrown errors? Cheers On Fri, Mar 19, 2010 at 4:53 PM, Vinzent Steinberg < vinzent.steinb...@googlemail.com> wrote: > 2010/3/17 Christian Muise : > > --- > > sym

Re: [PATCH 2/2] Removing the option for passing in a list of pairs, since the outcome is ambiguous when two pairs are given as arguments.

We have the raises() helper function, look in the tests for it. See for example: x = Symbol('x') raises(TypeError, "len(x)") It usually makes sense to have a test that proves your patch actually works. Here you could for example add a test that would lead without your patch to an "ambiguo

Re: [PATCH 1/2] Implemented the Implies class to compile away in the same sense as Xor, Nand, etc. One of the tests led to misleading results ('Implies(False, False) == False' should not hold), and

2010/3/19 Christian Muise : >   Looking at the implementation of Xor, Nand, Nor, and Not classes, it > appears that the aim is to maintain formulas in negation normal form ( > http://en.wikipedia.org/wiki/Negation_normal_form ). This would imply > (excuse the pun ;)) that the Implies class should d

Re: [PATCH 1/2] Implemented the Implies class to compile away in the same sense as Xor, Nand, etc. One of the tests led to misleading results ('Implies(False, False) == False' should not hold), and

> > I see, so I'm +1 on this patch. > Probably best to still get Fabian's input -- I haven't contributed to sympy before now so there may be some "bigger picture" issues that I'm failing to see. > Is there an advantage of having all in negation normal form? > For querying the theory? Not un

fix atan2() in sage

Hi, please review my 2 patches in "pu" branch at github: * ee232d5 (HEAD, github/pu, pu) atan2(y, x) can now be converted to/from Sage * 17806ba test_sage: Use S() instead of sympify() Thanks, Ondrej -- You received this message because you are subscribed to the Google Groups "sympy-patches"

Re: fix atan2() in sage

On Fri, Mar 19, 2010 at 7:01 PM, Ondrej Certik wrote: > Hi, > > please review my 2 patches in "pu" branch at github: > > * ee232d5 (HEAD, github/pu, pu) atan2(y, x) can now be converted to/from Sage > * 17806ba test_sage: Use S() instead of sympify() please review also these patches in the same b

Fixed all but one audit warnings in printing

Hi, There is one warning remaining about a method in the pretty printing code that does not seem to be used anymore. I'm not sure how to handle it. The rest was trivial to fix. The audit also revealed a bug in mathml. It is fixed in this patch and a corresponding test is added. Audit is re