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?
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]
???
Aaron Meurer
On Fri, Nov 12, 2010 at 9:11 AM, Øyvind Jensen <jensen.oyv...@gmail.com> wrote:
> Hi Omar,
>
> It is extremely cool that you want to work on this, don't hesitate to
> ask if you encounter any difficulties! When you start hacking, it would
> be very cool if you upload early and regularly to github. I'd be very
> interested in your work! I've got some suggestions based on stuff I was
> struggling with during the summer.
>
> I agree that the best way to improve it, is to implement printing of Sum
> objects. However, implicit summation is powerful, so it would be great
> if we can keep the implicit summation stuff, while adding the code
> printing of Sum objects. To do that, I think we need to improve the
> Indexed classes as well, as there may be a conflict between the implicit
> and explicit summation conventions.
>
> The current Indexed, Idx and IndexedBase classes behave like indexed
> tensors in the sense that,
>
> A[i] == A[j] .
>
> The indices label the same axis, no matter what you call the index.
> This is in contrast to indexed symbols that represent elements. For
> elements i and j of a vector A, the general relation is that
>
> A[i] /= A[j] .
>
> In order to implement printing of Sum objects, it is the element
> interpretation that must be represented in the Sympy expression tree.
> Perhaps you need to introduce a new class to represent the scalar
> elements? If you do that I'd suggest that they should also be created
> from IndexedBase, e.g. something like
>
>>>> i, j = symbols('i j', dimension=N, integer=True)
>>>> A = IndexedBase('A')
>>>> A[i, j]
> IndexedElement(A, i, j)
>
> If IndexedBase.__getitem__ checks whether the indices are Idx or Symbol,
> it can decide whether to return Indexed (like today) or IndexedElement.
> I've had plans along this direction for a while, and if you think it
> will work for you, I'd say you shouldn't hesitate to implement it.
>
> Cheers,
> Øyvind
>
> PS! Cool project!
>
>
> to., 11.11.2010 kl. 01.40 -0800, skrev Omar Awile:
>> Hi Øyvind
>>
>> Thanks a lot! Indeed that's a dirty hack, but it produces the desired
>> result :)
>> I'd be interested in actually fixing this. So maybe if I take some
>> time to understand how sympy expressions are parsed and how exactly
>> your printing works I could help in finding a good solution for this.
>> Actually I was asking myself the same question as Aaron, why not use
>> the sympy sum function?
>>
>> Answering your and Ondrej's question: Maybe "on the fly" was not
>> completely correct. I am currently working on PPM (http://www.ppm-
>> library.org/) a parallel library for particle-mesh simulations. The
>> library provides data structures for the particles and meshes,
>> routines for decomposing the problem, and handling all the
>> communication. It lets the user write his particle simulation using
>> those abstractions without having to worry about how to parallelize
>> the code. Now I'm thinking about how writing such simulations can be
>> further simplified. So, I'm working on a simple python API that one
>> can use to write his simulation code that will emit the complete
>> fortran code. And using sympy the user could almost write down the
>> discretized PDEs and get the corresponding fortran loops...
>>
>> cheers,
>>
>> omar
>>
>> On Nov 10, 10:34 pm, Øyvind Jensen <jensen.oyv...@gmail.com> wrote:
>> > > I am very interested in how you insert the code into your fortran
>> > > code. Do you generate a simple module, compile it and link it? Or how
>> > > do you insert it on the fly?
>> >
>> > Yeah, that would be interesting to hear about!
>> >
>> > Øyvind
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > > Ondrej
>>
>
>
> --
> 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.
