Aaron S. Meurer wrote:
>
> On Jul 22, 2009, at 1:10 AM, Fabian Pedregosa wrote:
>
>> Aaron S. Meurer wrote:
>>> How do you actually attach assumptions to variables? The old style
>>> keyword argument to Symbol doesn't seem to work. I know that you can
>>> pass Assume objects to query(), but is there a way to globally define
>>> x as positive?
>>> In [1]: x = Symbol('x', positive=True)
>> Hi Aaron. There is a way to define global assumptions, although I
>> haven't used it much:
>>
>> In [1]: register_global_assumptions(Assume(x, positive=True))
>>
>> In [2]: query(x, positive=True)
>> Out[2]: True
>>
>
> I see. Whenever we get this merged, will Symbol('x', positive=True)
> call register_global_assumptions on x? If so, that will be fine.
I don't think that will be the case, because Symbol('x', positive=True)
gives the impression that assumptions are binded with symbols, but this
is not the case anymore.
>
>> you can then clear them with clear_global_assumptions(). I'll add this
>> info to doc/src/modules/queries.txt
>>
>>> In [2]: query(x, positive=True)
>>> <returns None>
>>>
>>> In [3]: Assume(x, positive=True)
>>> Out[3]: Assume(x, positive=True)
>>>
>>> In [4]: query(x, positive=True)
>>> <returns None>
>>>
>>> In [5]: sqrt(x**2)
>>> Out[5]: x
>>>
>>> In [6]: sqrt(y**2)
>>> Out[6]:
>>> ⎽⎽⎽⎽
>>> ╱ 2
>>> ╲╱ y
>>>
>>> In [9]: Assume(y, positive=True)
>>> Out[9]: Assume(y, positive=True)
>>>
>>> In [10]: sqrt(y**2)
>>> Out[10]:
>>> ⎽⎽⎽⎽
>>> ╱ 2
>>> ╲╱ y
>>>
>> The new system won't reduce expressions based on assumptions. This
>> will
>> be done by a function called refine (see mathematica's Refine)
>>
>>> So the reduction of sqrt(x**2) comes from the old assumptions, not
>>> the
>>> new ones. I realize that not everything is implemented yet, but it
>>> seems that at least [4] should return True.
>> Yes, the price to pay in exchange is a small sacrifice in speed.
>> That is
>> why methods in the core should not use query() directly. They should
>> test properties based on class membership and leave assumption-related
>> simplification to refine().
>>
>>> For example, in Maple, typing assume(x, positive) changes the
>>> variable
>>> x to be positive everywhere. You can also use "assuming" to only
>>> assume for one expression:
>>
>>
>>>> x;
>>> x
>>>> assume(x, positive);
>>>> x;
>>> x~ (the tilde indicates that x
>>> has an assumption on it)
>>>> is(x, positive);
>>> true
>>>> coulditbe(x, negative);
>>> false
>>>> sqrt(x**2)
>>> x~
>>>> sqrt(y**2) assuming y::positive;
>>> y
>>>> sqrt(y**2);
>>> (1/2)
>>> / 2\
>>> \y /
>>>
>>> See http://www.maplesoft.com/support/help/view.aspx?path=assume for
>>> more info on the Maple assumptions system.
>>>
>>> The actual querying of facts seems to work well when you pass
>>> assumptions to query().
>>> In [1]: Assume(x, negative=True, positive=True)
>>> AssertionError: ('inconsitency between facts', {'real': True,
>>> 'nonzero': True, 'commutative': True, 'nonpositive': False,
>>> 'positive': True, 'negative': False, 'nonnegative': True, 'zero':
>>> False, 'complex': True, 'imaginary': False}, 'negative', True)
>>>
>>> In [2]: query(x, real=True, assumptions=Assume(x, positive=True)) #
>>> this always bothered me for not working in the old assumption system.
>>> Out [2]: True
>>>
>>> query() seems to be like the Maple is(). Will we also have something
>>> like Maple's coulditbe()?
>>
>> I am not familiar with Maple, but since query() returns None when it
>> can't say, I think coulditbe() is just:
>
> See my link above for more info on Maple's assumptions system.
>> In [1]: def coulditbe(*args, **kwargs):
>> ...: _q = query(*args, **kwargs)
>> ...: if (_q is True) or (_q is None): return True
>> ...: return False
>>
>>
>> In [2]: register_global_assumptions(Assume(x, positive=True))
>>
>> In [3]: coulditbe(x, negative=True)
>> Out[5]: False
>>
>>
>> If this is correct, then I don't think it is worth to implement
>> coulditbe
>
> coulditbe() returns True if there are any values of the variables that
> make the expression true. Maple also has is(), which only returns
> true if all values of the variables make the expression true. about()
> will print the exact assumptions.
> For example in Maple:
> > assume(x, integer);
> > coulditbe(x/2, integer);
> true
> > is(x/2, integer);
> false
> > about(x);
> Originally x, renamed x~:
> is assumed to be: integer
>
> In your branch, query seems to take a middle approach. It returns
> True if it is always True, but None if it is not always True, but not
> always False either (or if it cannot determine), and False if it is
> always False. Is this correct.
>
> In [2]: query(x/2, integer=True, assumptions=Assume(x, integer=True))
> <returns None>
>
> It is also common have inequalities as arguments to coulditbe():
> > assume(x, positive);
> > coulditbe(x < 1);
> true
> > is(x < 1);
> false
> > coulditbe(x < 0);
> false
>
> query() doesn't seem to support this yet, unless I am doing it wrong:
> In [3]: query(Ge(x, 1), assumptions=Assume(x, positive=True))
> KeyError: 'popitem(): dictionary is empty'
>
> I'm trying to think of an example of something that Maple could give
> your more information with its two functions than your single query()
> function. The only thing I can think of is the overloading of None in
> query to mean both that it cannot determine and that it could be True
> or False for different values. What do you think?
I've been working with this branch for some time, and I did not feel the
need for an extra coulditbe function ...
>
> Aaron Meurer
>>
>> Regards,
>>
>>> Aaron Meurer
>>> On Jul 21, 2009, at 2:02 PM, Fabian Pedregosa wrote:
>>>
>>>> In this series of 4 patches, I implement a new query system.
>>>>
>>>> You can also pull from my repo, branch master:
>>>>
>>>> git pull http://fseoane.net/git/sympy.git master
>>>>
>>>>
>>>>
>>>
>>
>> --
>> http://fseoane.net/blog/
>>
>
>
> >
>
--
http://fseoane.net/blog/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to this group, send email to sympy-patches@googlegroups.com
To unsubscribe from this group, send email to
sympy-patches+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sympy-patches?hl=en
-~----------~----~----~----~------~----~------~--~---
