Ok, thanks for the reply. I think it should be possible to make the new
system work without backwards chaining. So I won't focus on that for now.
On 13.04.2013 14:21, Matthew Rocklin wrote:
This came up in matrix expressions
https://groups.google.com/forum/?fromgroups=#!searchin/sympy/triangular$20/sympy/sOeIU6nz-gM/DoVGj1Ka_WMJ
My answer to this is that we might want to change how new assumptions
works but that this is ok. New assumptions can be broken up as follows
1. A nice way to write down known relations, both on specific classes
(handlers) and general inferences (known_facts dict)
2. Some nice inference logic in the logic module (haven't looked at this
much but I assume it's nice)
3. A specific scheme to combine the two.
Changing one of these around fortunately doesn't disrupt the others. I
think 3 could use some work both for performance and correctness.
> For example, in the special functions library, it seems much more
sensible to group knowledge by function instead of property
Yeah, it could go either way. In general we want to write down code for
each predicate/class pair. When we ask a question we want to quickly
find the right bit of code to provide an answer. Our two options seem
to be to index by predicate (new assumptions) or to index by class (old
assumptions). Both solutions have different problems of the same magnitude.
We could also group by neither and create some sort of centralized
database of known relations to which various pieces of code could
contribute. We would then need some way to efficiently query such a
database. Grouping by predicate or grouping by class are two specific
examples of indexing systems. If choosing between them feels arbitrary
then maybe we should look for a third solution.
In summary. I like the design of the pieces of new assumptions. I
think that we might want to reorganize them a bit. The beauty of this
system is that this is much easier to do than with old assumptions.
Changes to the backend are isolated from the accumulated mathematical
data.
On Sat, Apr 13, 2013 at 3:57 AM, Tom Bachmann <e_mc...@web.de
<mailto:e_mc...@web.de>> wrote:
Hi,
I spent the last two days studying in a bit more detail the new
assumptions system. Are we *sure* that it can replace the old one?
I'm asking in particular because the new system does not do any
automated backwards chaining. The new system basically works like
this. To compute ask(is_foo(x), facts), we first call
FooHandler.<type(x)>(facts). This can do specialised reasoning, like
x+y>0 provided x>0 and y>0. This specialised code is also allowed to
call ask recursively (e.g. on subexpressions).
If this fails, we forget about the specialised handlers completely,
and try to deduce foo (or not foo) from the facts alone, via a set
of logical inference rules.
That is, in order to have backwards chaining, the handlers have to
implement it by hand! For example, we have the implication
(positive=>nonzero). Cosider the query ask(Q.nonzero(expr)). Suppose
there is a specialised positive handler for expr, but not a nonzero
handler. Then the result will be None.
Note that the problem goes away if we require a full set of handlers
to be implemented for each type. Is this desired? Or should I
implement backwards chaining?
Also, a question about code organisation. In the new assumptions
system, knowledge is expressed in "handlers", distinct from the
actual objects. Instead, the knowledge is grouped by property. E.g.
there is an AskPositive handler, which contains all the knowledge
about when objects are positive (although there can be several such
handlers). Does that make sense in general. For example, in the
special functions library, it seems much more sensible to group
knowledge by function instead of property.
Thanks,
Tom
--
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.
