There are two different systems in sympy to represent facts; these are our
two assumptions systems.

In the old version expressions have facts attached to them
x = Symbol(x, positive=True)

In the new version they are separate
x = Symbol(x)
facts = Q.real(x)

There are two problems:
1. Neither system is able to handle x>y facts except for simple cases (e.g.
for y == 0). The new system should be able to handle a simple version
easily. It might be more challenging to do more serious inference.
2. Even if we fixed this much of the code still uses the old system.

This has been one of the top issues in SymPy for a long while. If we had
some mechanism to associate bounties to issues this would probably have the
highest.




On Wed, Nov 14, 2012 at 2:37 PM, Simon Clift <[email protected]> wrote:

> Hi Matthew,
>
> This does appear to be the case.  I've just looked over facts.py and
> assumptions.py as well.
>
> Interval._intersection evaluates the comparisons and there is an explicit
> comment about not doing comparisons on Symbol classes on line 539
>
>         # We can't intersect [0,3] with [x,6] -- we don't know if x>0 or
> x<0
>         if not self._is_comparable(other):
>             return None
>
> That would leave open the question of how best to put such machinery into
> the Symbol class.
>
> It's not clear to me, BTW, what distinguishes something that belongs in a
> FactKb from something that is denoted with a member function such as
> Symbol.is_comparable.  I gather that "facts" are static (e.g. "this is a
> real") rather than contextual (e.g. "this A \in \Real < B \in \Real") but
> doesn't that leave such facts out of the scope of the rules engine?  Seems
> like there is an opportunity there for a lot more power in the system.
> Just reviewing, for example, my analysis text there are a lot of "facts"
> that might be useful for proofs or reasoning about expressions.  I imagine
> that's getting out of scope for Sympy, perhaps?
>
> It seems to me that something could be shoe-horned in, but I'd be afraid
> of doing something inadequately generalized.
>
> Thanks
> -- Simon
>
>
> On Wednesday, 14 November 2012 15:01:46 UTC-5, Matthew wrote:
>
>> I'm not very knowledgeable on this part of SymPy though. Hopefully I am
>> wrong.
>>
>> On Wed, Nov 14, 2012 at 2:01 PM, Matthew Rocklin <[email protected]>wrote:
>>
>>> My understanding is that SymPy is not able to handle information like
>>> `assume(A<B)`. This has been on our issues list for a while I think.
>>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/sympy/-/Dalk6tMLV3gJ.
>
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Reply via email to