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> 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<sympy%2bunsubscr...@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<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.
