assume(x < y) is an open issue ( https://code.google.com/p/sympy/issues/detail?id=2721). For now, you might be able to work with assume(Q.positive(x - y)). But it doesn't look like automatic reasoning about that is implemented yet:
In [17]: ask(Q.positive(x - z), Q.positive(x - y) & Q.positive(y - z)) <None> The logic is simple enough in this case, though, that you can probably just implement it from scratch. Definitely if your endpoints are just Symbols (not Adds) it will be simple. Beyond that, maybe the inequality solver (in solve()) can do some reasoning for you? Aaron Meurer On Wed, Nov 14, 2012 at 1:01 PM, Matthew Rocklin <[email protected]> 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. >> >> >> On Wed, Nov 14, 2012 at 1:58 PM, Simon Clift <[email protected]> wrote: >> >>> Digging. I'm looking to hack something in to support symbolic intervals >>> and need some advice, please. >>> >>> I'm getting my problem laid out as an intersection, but I'm hitting a >>> problem performing the calculation symbolically. If I have >>> >>> A,B,C,D = symbols( ( "A", "B", "C", "D" ), real=True ) >>> >>> i_ab = Interval ( A, B ) >>> i_cd = Interval ( C, D ) >>> >>> i_chk = Intersection( i_ab, i_cd ) >>> >>> then in line 449 of core/sets.py I don't have the is_comparable >>> property. I was looking through the core/relational.py code for an >>> operator that would allow me to impose a strict ordering, say A < C < B < D >>> (in Maple I would use something like assume(A<B) ). Is there an accepted >>> way of attaching an is_comparable type operation to the individual Symbol >>> objects, say: >>> >>> A.is_lessthan( C ) >>> >>> which would (say) set >>> >>> A.is_comparable = True >>> A.comparison_dict = { C : '<' } >>> >>> or something suitably Sympy-compatible? Should I fear combinatoric >>> complexity problems evaluating that? >>> >>> Thanks >>> -- Simon >>> >>> >>> On Monday, 12 November 2012 15:15:52 UTC-5, Matthew wrote: >>>> >>>> If you do go digging around in the code I'd probably suggest working >>>> with sympy.core.sets rather than sympy.stats. sympy.core.sets is better >>>> organized and has a much lower entry barrier. >>>> >>> -- >>> 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/-/X8YHtVh_nJcJ. >>> >>> 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. > -- 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.
