Hi Øyvind, Aaron
Sorry for the late reply.. it took me some time to digest all this :)
I also went through the code in the fcode and the index* modules. I
think it will take me considerable time to wrap my head around the
relevant parts of the sympy code to understand how to extend it. I was
also wondering if you guys anyway had immediate plans to extend fcode
functionality or if for you the existing is good enough. I definitely
would like to be involved in extending this, but it will take me some
time to even be at the point of being able to extend the existing
code.
cheers,
omar
On Sat, Nov 13, 2010 at 20:20, Aaron S. Meurer <asmeu...@gmail.com> wrote:
>
> On Nov 13, 2010, at 4:23 AM, Øyvind Jensen wrote:
>
>> fr., 12.11.2010 kl. 11.19 -0700, skrev Aaron Meurer:
>>> If I understand you correctly, you will implicitly sum over Symbol
>>> indices and loop over Idx indices, right? If so, that sounds like a
>>> good idea, except why do you want to use Symbol instead of creating a
>>> new class?
>>
>> Well, maybe a new class is better, I'm not sure. The idea was to allow
>> implicit summation with repeated indices of class Idx as it is done
>> today, and use something else for indices that are not subject to
>> implicit summation.
>>
>>>
>>> I'm also confused about creating one class vs. another. What would
>>> happen in your model if you mix both, like
>>>
>>>>>> i = Idx('i')
>>>>>> j = Symbol('j', dimension=N, integer=True) # Or whatever you end up doing
>>>>>> A[i, j]
>>> ???
>>
>> That's a good question. Maybe there should only be one Indexed class
>> that can handle indices of various types. It may be the cleanest
>> approach. If I recall correctly this is the way covariant and
>> contravariant indices are implemented in GiNaC: In addition to an Idx
>> class, GiNaC has a VarIdx class for indices with given variance. We
>> should also be able to follow this approach for variance, and it may be
>> a good approach for elemental indices as well.
>
> I agree. Just put the type as a keyword argument to Idx, and store it as a
> property of the element (unless the two different things really are different
> enough that they deserve to be different classes).
>
> Aaron Meurer
>
>>
>> To follow that approach, I think we are going to need
>>
>> 1) some representation of elemental indices (Symbol? ElemIdx?
>> FixedIdx? ...)
>> 2) improvements to sympy.tensor.indexed.Indexed
>> 3) some changes in sympy.tensor.index_methods
>> 4) printing of Sum in the code printers
>>
>> Øyvind
>>
>>
>>>
>>> Aaron Meurer
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sy...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> 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 sy...@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> 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 sy...@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
