Hm, I see what you are saying (I think). Basically much of sympy expects
`expr.func(*expr.args)` to be a no-op, except possibly if args is empty
or expr is an atom.
Solution (1):
Have .assumptions only valid on atoms with empty args, where we expect
not to be able to use the expr.func(*expr.args) pattern anyway. That
might be the easiest way to go.
Solution (2):
Even for non-atoms, we can allow .assumptions to be computed from the
class, as you point out. This would be a reasonably nice way to avoid
moving simple properties too far from their classes, but should probably
be thought about more carefull.
Solution (3):
Never allow .assumptions to contain extra data; require the assumptions
on symbols to be stored in the .args.
This is less resilient than (1) but might be cleaner in the long run, if
we decide to keep assumptions on symbols.
I'm adding (1) as a minimal solution to my proposal, and will discuss
possibilities (2) and (3) in a stretch goals section (to be written).
Thanks!
On 14.04.2013 14:34, Matthew Rocklin wrote:
I'd like it if only `Atom`s had the extra data and all other Basics
computed assumptions from their leaves and potentially their class.
Is it possible to keep Symbol.assumptions stored in Symbol.args ? That
way we keep the simple tree structure. We'd need to be more careful
about is_Atom checks rather than relying on empty args.
On Sun, Apr 14, 2013 at 3:48 AM, Tom Bachmann <e_mc...@web.de
<mailto:e_mc...@web.de>> wrote:
Just NB: the reason why I don't like Symbol('x', positive=True) to
return PositiveObject(Symbol('x')) is that (a) it hides facts from
the inference engine, and (b) for this to scale beyond Symbol and
Dummy, every client will have to be prepared to strip the
PositiveObject wrapper in order to deal with the wrapped object.
Neither of these is a very strong argument - (a) just shows a
shortcoming of the ask() implementation, and (b) would be does not
really apply as long as we are just trying to emulate the old behaviour.
Tom
On 14.04.2013 00:13, Aaron Meurer wrote:
This looks very good so far. I have just some comments, which
perhaps
should be forked into another one of your mini-threads
- If you are planning on making any changes to the cache, you might
want to take a look at bin/test -C and see what sorts of issues
currently exist with it. There is also a caching label in the
tracker.
- Regarding Symbol('x', positive=True), I think this requires some
thought. I am beginning to think that actually the best way to
do this
is to keep doing it like we do it now (modulo some refactoring
of the
Symbol class).
I think perhaps there needs to be a separate set of global
assumptions, which are assumptions that never change. For example,
Q.positive(pi) (from my understanding this currently works by
calling
.evalf(); we should see if it's faster to do that or to store a
bunch
of Q.positive(pi) and so on explicitly, but anyway, not all custom
object assumptions can be generalized like this) never changes,
and so
it should never be cleared, and additionally any facts resulting
from
it should never be cleared.
In general, we want to allow objects to define their own assumptions
about themselves, so that things can remain modular, and so that
objects in user-land can work as first-class citizens with the
assumptions. So, given that, I think that Symbol('x', positive=True)
should be no different. This "keeps the assumptions in the
core", but
really, the issue is the inference code in the core. So I would just
leave Symbol('x', positive=True) alone for now, and refactor how it
works internally once we have a good API for how custom objects
define
their own assumptions on themselves.
- It occurs to me that another advantage of using the "switch"
method
for switching over to the new assumptions is that it will become
clear
exactly what sorts of behaviors we are going to have to deprecate or
completely remove, giving us an idea of the impact on users in the
next release.
Aaron Meurer
On Sat, Apr 13, 2013 at 4:18 PM, Tom Bachmann<e_mc...@web.de
<mailto:e_mc...@web.de>> wrote:
Hi,
I have spent the last couple of days writing up a more
coherent proposal. It
is now in a readable state, see [1]. Any comments would be
appreciated. (The
proposal is still slightly rough, in particular there are a
few TODO notes,
and I haven't written anything yet about stretch goals.)
Matthew:
I have not forgotten your email from april 10,
It might be nice to have a couple representative
bugs/issues. What are
the sorts of problems that we're facing?
What is a specific piece of code that would break?
What is an important routine that would run much more
slowly?
I just have not had time do work out an answer, yet.
Anyone else, if I have not addressed one of your concerns,
please let me
know.
Thanks,
Tom
[1]
https://github.com/sympy/__sympy/wiki/GSOC-2013-__Application-Tom-Bachmann:-__Removing-the-old-assumptions-__module
<https://github.com/sympy/sympy/wiki/GSOC-2013-Application-Tom-Bachmann:-Removing-the-old-assumptions-module>
--
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+unsubscribe@__googlegroups.com
<mailto:sympy%2bunsubscr...@googlegroups.com>.
To post to this group, send email to sympy@googlegroups.com
<mailto:sympy@googlegroups.com>.
Visit this group at
http://groups.google.com/__group/sympy?hl=en-US
<http://groups.google.com/group/sympy?hl=en-US>.
For more options, visit
https://groups.google.com/__groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
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+unsubscribe@__googlegroups.com
<mailto:sympy%2bunsubscr...@googlegroups.com>.
To post to this group, send email to sympy@googlegroups.com
<mailto:sympy@googlegroups.com>.
Visit this group at http://groups.google.com/__group/sympy?hl=en-US
<http://groups.google.com/group/sympy?hl=en-US>.
For more options, visit https://groups.google.com/__groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
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.
--
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.
