Hi Tom,

On Mon, May 20, 2013 at 8:40 AM, Tom Bachmann <e_mc...@web.de> wrote:
> Sorry for taking a while to respond. I have been away for the weekend.
>
>
> On 17.05.2013 04:13, Ondřej Čertík wrote:
>>
>> Hi,
>>
>> I came late to this discussion. I have a few questions. It seems that
>> the consensus is to use global assumptions together with the
>> "assuming" context manager.
>> Let's take Pow as an example. In the Pow.__new__(), resp in
>> Pow._eval_power() it currently uses code like:
>>
>>          b_nneg = b.is_nonnegative
>>          if b.is_real and not b_nneg and e.is_even:
>>              b = abs(b)
>>
>> and so on. So these are the old assumptions. So the idea is to replace
>> this code with something like:
>>
>> b_nneg = ask(Q.nonnegative(b))
>> if ask(Q.real(b)) and not b_nneg and ask(Q.even(e)):
>>      b = abs(b)
>>
>> This "ask" would use the global assumptions dictionary. Is my
>> understanding correct?
>>
>> I think that this is a step in the right direction. However, I do have
>> an important comment.
>>
>>
>> My idea about assumptions is the following. There are no global
>> assumptions by default (though they could and should be added for
>> convenience, but by default there are none and things work without
>> them just fine).
>> The above code would get replaced with:
>>
>> b_nneg = ask(assume, Q.nonnegative(b))
>> if ask(assume, Q.real(b)) and not b_nneg and ask(assume, Q.even(e)):
>>      b = abs(b)
>>
>> Where "assume" is a keyword argument, that gets passed into
>> Pow.__new__() as follows:
>>
>> Pow(a, b, assume=Q.positive(a)&  Q.even(b))
>>
>
>
> There are a number of issues you are conflating here. The first rewrite
> (replacing b.is_nonnegative by ask(Q.nonnegative(b))) is completely
> mechanical and seems a bit pointless to me. It seems more reasonable to just
> redefine the .nonnegative attribute/method to call ask directly.

Very good idea, that didn't occur to me. And I like this, as this will
mean (hopefully)
quite minimal changes to sympy, while still getting rid of the old assumptions.

Then we can go from there.

>
> The second half (about the local assume keyword) is somewhat more radical.
> It changes not only the internal implementation, but also the external
> behaviour of the code.
>
> Let me try to explain where my proposal fits in.
>
> The main aim of my assumptions proposal is to change the assumptions
> implementation, more or less without changing the external behaviour. That
> is to say I want to get rid of the ManagedProperties meta class, and
> associated stuff (like FactKB etc). Of course that is not the motivation,
> but only the practical effect. I have detailed this in melange, but this
> replacement is essentially an "engineering challenge", and not a matter of
> policy. So what needs to be done is roughly:
>
> - move the fact deduction logic scattered throughout classes into
>   handlers (i.e. new assumptions), where this has not been done yet
> - remove the implementations of .is_foo which use the old assumptions,
>   replace them by calls to ask
> - fix functionality problems that come up in this
> - fix performance problems
>
> So my proposal is basically to execute the first rewriting you have
> illustrated above. It does not principally include policy changes, like
> introducing a new assume keyword argument, or change of external behaviour,
> etc. That may seem like less than desirable (and I agree), but I hope I have
> made it clear in my proposal why I think this deceiptively modest goal is
> aready hard to achieve.

This is actually the hardest goal. And I fully support that you want
to do it without
changing many policies, as then we can all agree that this has to be
done anyway.

>
>
> Of course, once this is done, the doors are wide open for all sorts of
> policy changes, implementation of more fancy strategies, etc. I have tried
> not to focus on this in my proposal, for one thing because I do not plan to
> work on it (much), but more importantly because this is not something I
> think a single person can design, but rather we will have to work it out as
> a community.

Fully agree. Once old assumptions are gone, we'll go from there.

>
> To me personally it seems a bit cumbersome to carry around all the
> assumptions in a separate keyword argument, hence why I like the context
> manager. But in principle, such an extension would be straightforward once
> the new assumptions are in place. As a matter of fact, it is even possible

The whole point of my email is that it should be possible to override
global assumptions,
that's all. There might be other ways to implement such a feature, for
example with
some clever new context manager. So I think we should keep this point in mind.

> to add the "assume" keyword functionality *without changing most of sympy*,
> as I have explained in the speculative "autorefinement" section of my
> proposal.

We discussed some of this above. One option is to make refine() call
things like Pow._refine(), that way the actual simplification will stay local
to the class itself. It's true that there will be some duplication of the code
in Pow.__new__() and Pow._refine(). As discussed above, my hope is that
one could even unify somehow the two methods, but anyway, we'll have
a much better idea after old assumptions are gone.

>
> I hope this helps clearing up the relation between my proposal and your
> ideas.

Yes, thank you. I think it is all clear and I agree with your points/proposal.

Ondrej

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to