On Fri, Sep 19, 2014 at 1:52 PM, Aaron Meurer <asmeu...@gmail.com> wrote: > On Fri, Sep 19, 2014 at 9:20 AM, James Crist <crist...@umn.edu> wrote: >>> it looks like in the first example that the expression is returned >>> directly while in the second case it is not(?) >> >> >> Ideally, for routines with one expr, `routine` and `routine[0]` will be >> identical. Not sure if this is possible, and I may decide that's too much >> magic. The main purpose behind all this is to make a more composable way of >> combining underlying compiled code. > > I don't think that's a good idea. To me, Routine((a, b, c), expr) and > Routine((a, b, c), (expr,)) should be different. > >> >> After playing around for a bit, it looks like this is going to be >> complicated. Even combinatorial operations (add, mul, etc...) call methods >> that refer to the underlying expression being computed. I'm not sure of the >> best way to do it, but right now I'm thinking I'll make a list of operations >> I want to be aliased to the underlying expression. Then I'll redefine >> `__getattribute__`, and redirect requests to the expression if they're in >> that list. That still may end up being too complicated, and I may have to >> rethink my approach. > > __getattr__, not __getattribute__. Don't override __getattribute__ > unless you really know what you are doing. > > Something like > > def __getattr__(self, attr): > if attr.startswith('_eval_is_'): > return getattr(self.expr, attr)
Oops, there should be a raise AttributeError here. Otherwise all other attributes will give None. Aaron Meurer > > For an applied routine, you probably want to substitute the values in > first as that can affect the assumptions. > > Aaron Meurer > >> >> On Fri, Sep 19, 2014 at 9:00 AM, Chris Smith <smi...@gmail.com> wrote: >>> >>> The assumptions system will try to call `_eval_is_foo` if it exists for >>> the object. So if you add definitions for ``_eval_is_integer` to your >>> Routine object you can return the value of `is_integer` for the return >>> value. I suspect there will be issues with how you define Routine, however, >>> since it looks like in the first example that the expression is returned >>> directly while in the second case it is not(?). >>> >>> >>> On Thursday, September 18, 2014 10:32:01 PM UTC-5, James Crist wrote: >>>> >>>> I have a new SymPy type that serves to represent a unit of computation >>>> (contains an expression/expressions that is/are being computed). I'd like >>>> to >>>> be able to alias queries on the assumptions of the element to assumptions >>>> of >>>> the underlying expression it represents. Example: >>>> >>>> >>> a, b, c = symbols('a, b, c', integer=True) >>>> >>> expr = a + b + c >>>> >>>> # Create the tree element >>>> >>> r = Routine((a, b, c), (expr)) >>>> >>>> # r now represents a computational routine. >>>> # We can use this as a function in other expressions. >>>> >>> new_expr = 1 + 2 + r(a, b, c) >>>> >>> new_expr >>>> 1 + 2 + r(a, b, c) >>>> >>>> # The following should work >>>> >>> new_expr.is_integer >>>> True >>>> >>> r(1, 2, 3).is_integer >>>> True >>>> >>>> For `Routine` objects with multiple returns, the results are indexed to >>>> select the output element: >>>> >>>> >>> exprs = (a + b + c, a*b*c + 4.1) >>>> >>> r = Routine((a, b, c), exprs) >>>> >>>> # Use it in a new expression >>>> >>> (1 + r(1, 2, 3)[0]).is_integer >>>> True >>>> >>> (1 + r(1, 2, 3)[1]).is_integer >>>> False >>>> >>>> Any idea how to go about doing this? I have little to no understanding of >>>> the assumption system, so before I start digging through the code I thought >>>> I'd ask if anyone had thoughts on how to tackle this. The `Routine` type, >>>> the `AppliedRoutine` type, and the results/arguments are all done. I just >>>> need to figure out (if possible) how I can make this play well with the >>>> assumption system. >>>> >>>> -Jim >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "sympy" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/sympy/XX4K-OhvqTU/unsubscribe. >>> To unsubscribe from this group and all its topics, 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. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/sympy/7c9a540b-7661-40ab-8f99-39ddeef19f9c%40googlegroups.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> 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. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/CAJ2L7mdh7ObsxOv_rmiH8NaF%3Di6kNnoX5jq2f2XLBYs6uzaDQQ%40mail.gmail.com. >> >> For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6L%2Bo5VT8Tpfv0qyRe%3DpBubFHMaWX9wPkJ15AfStwCbGmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.