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.
