On Mon, Nov 28, 2011 at 12:46 AM, Mateusz Paprocki <[email protected]> wrote: > Hi, > > On 27 November 2011 05:59, Aaron Meurer <[email protected]> wrote: >> >> This is an interesting question. Definitely is_zero should work. >> >> Actually, it's not so bad. It's just not implemented enough to know >> that zero + zero == zero: >> >> In [4]: a.is_zero >> Out[4]: True >> >> In [3]: var('a b',positive=False,negative=False,real=True, zero=False) >> AssertionError: ('inconsistency between facts', {'real': True, >> 'prime': False, 'comparable': False, 'commutative': True, 'composite': >> False, 'positive': False, 'negative': False, 'zero': False, 'complex': >> True, 'imaginary': False, 'nonzero': True}, 'real', False) >> >> I think this should be considered in the context of the new >> assumptions system, because that is what we eventually use. There, >> the refine() function simplifies expressions based on assumptions. >> Right now it doesn't work for this: >> >> In [7]: refine(a, ~Q.positive(a)&~Q.negative(a)&Q.real(a)) >> Out[7]: a >> >> But I think what we should look at is making refine smart enough to do >> this, rather than trying to fix the old system to be smart about these >> things, because, again, the old system is going away. Not only that, >> but there's a reason that we're going with a model where you call >> refine rather than things trying to simplify automatically. > > With new assumptions adding such feature is very simple, e.g.: > ~/repo/git/sympy$ git diff > diff --git a/sympy/assumptions/refine.py b/sympy/assumptions/refine.py > index ab7c34e..b7a0c9b 100644 > --- a/sympy/assumptions/refine.py > +++ b/sympy/assumptions/refine.py > @@ -153,8 +153,13 @@ def refine_exp(expr, assumptions): > elif ask(Q.odd(coeff + S.Half), assumptions): > return S.ImaginaryUnit > > +def refine_Symbol(expr, assumptions): > + if ask(~Q.nonzero(expr), assumptions): > + return S.Zero > + > handlers_dict = { > 'Abs' : refine_abs, > 'Pow' : refine_Pow, > 'exp' : refine_exp, > + 'Symbol' : refine_Symbol, > } > ~/repo/git/sympy$ bin/isympy -q > IPython console for SymPy 0.7.1-git (Python 2.7.2-64-bit) (ground types: > gmpy) > In [1]: refine(x, ~Q.nonzero(x)) > Out[1]: 0 > In [2]: refine(x, ~Q.negative(x) & ~Q.positive(x) & Q.real(x)) > Out[2]: 0 > I'm just curious why there is Q.nonzero and not Q.zero. Also, I'm not sure > about the following: > In [3]: refine(x, ~Q.negative(x) & ~Q.positive(x)) > Out[3]: 0 > In [4]: refine(x, ~Q.negative(x)) > Out[4]: x > Shouldn't assumption in [3] be understood as zero and all complex numbers > with non-zero imaginary part? In this case the result should be x.
I guess nonzero implies real for some reason: In [12]: ask(Q.real(x), Q.nonzero(x)) Out[12]: True And I guess we don't have Q.zero() because this set contains a single point, so you might as well just use .subs(), at least as far as assuming goes (asking is a different story). This is the problem with assumptions like nonzero, nonnegative, irrational, etc. They all mean "not (zero, negative rational, ...)" *and* "real", when they might appear to just mean "not (zero, negative, rational, ...)". It's also why we desperately need to decide *exactly* what each assumption will mean, and document it (http://code.google.com/p/sympy/issues/detail?id=2196) before we do any work on the new assumptions. In addition to this confusion, we also need to clarify what sets the infinities belong to. For example, we currently have the following contradictory set of facts: In [13]: ask(Q.real(oo)) Out[13]: False In [14]: ask(Q.positive(oo)) Out[14]: True In [15]: ask(Q.real(x), Q.positive(x)) Out[15]: True Again, we need exact definitions here, so we know, for example, if positive means (0, oo) or (0, oo]. I created http://code.google.com/p/sympy/issues/detail?id=2877 for this last example. Aaron Meurer > >> >> Aaron Meurer >> >> On Thu, Nov 24, 2011 at 9:16 PM, smichr <[email protected]> wrote: >> >>>> var('a b',positive=False,negative=False,real=True) >> > (a, b) >> >>>> a+b >> > a + b >> >>>> _.is_zero >> > >> > Should such symbols be allowed or should 0 have been returned instead? >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "sympy" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > 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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/sympy?hl=en. >> > > Mateusz > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
