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.
