> Hi sympy team,
>
> I'm interested in this issue, and as Kent-Andre Mardal sits approx. 150cm
> from my office, we are quite synchronized. Actually, since the sympy license
> is less restrictive than that of GiNaC, I'm considering using sympy as backend
> to some of my software instead of swiginac.
>
> Defaulting to a cross platform backend sounds resonable, although it currently
> comes at the price of performance.

There is also a sympycore project, done be Pearu and Fredrik, which
tries new approaches to speed SymPy up, still in pure Python.
Is Pearu also sitting 150cm from your office? :)

> Ideally, the only syntax difference in sympy and swiginac should be the import
> statement. Today, this is not 100% the case. Perhaps we should have a
> discussion regarding this issue? It would be possible to add a wrapper layer

Yes.

> in Python layer a-la Symbolic, but I don't think it makes enough sense to
> justify the cost of maintenance. There will always be differences in the set
> of provided features, but it would be nice if the intersection in
> functionality shared a common syntax (and semantics).

Agree, the common syntax should be the same. There is another project,
SAGE, and I also would like to have the same syntax with them, if
possible.

So let's create the SymFE, calling both swiginac and sympy as a
backend, and then we will see exactly which syntax things needs to be
fixed.

> > Yes, let's do that. However, there should be a leader, who will push
> > things forward and make sure it is coordinated. Is anyone willing to
> > do it?
>
> I have started nagging about making the project, but so far I am not
> very familiar neither with sympy nor with swiginac... However I can
> setup a project at googlecode, if you want.

Setting up a project on googlecode is the least thing. :) I meant,
that the leader needs to be motivated for the project to succeed and
push it forward.
But let's just create the project for now and try it. If you do it,
add me as a member please.

> > What name to use - SymFEM? It needs to be a name, that is easy to
> > google, symfem is.
>
> I like it. Maybe only SymFE?

Sounds good to me.

> > How about calling sympy by default, so that it works in pure python
> > (easy to install, works on windows/linux/mac os x for free), and
> > calling swiginac optionally for speed? And also trying to speed sympy
> > up (my bet is on Cython[1]). This means converging with the interface
> > of swiginac and sympy. Since I am a coauthor of both, it shouldn't be
> > that difficult.
> > But swiginac is now under the hood of Ola Skavhaug, I didn't really
> > touch it for two years - but I think Ola will also be interested in
> > that (CCing him)? See related posts to sympy mailinglist[2].
>
> This would be great, but it should not be too visible to user (=me :-)
> The less _required_ dependencies the better.

Yes. The python will be default for sure in SymPy. It's just pain to
compile anything. But optionally it would be nice. I think I am
talking about this too much, talk is cheap. I should try to do some
easy arithmetics stuff in Cython now, to see if it really speeds
things up.

> I am happy with the BSD license.
>
> What we do now in the fenics projects ffc, fiat and syfi is that
> based on a python description of a finite element method we generate
> C++ code. Furthermore, this C++ code is then wrapped by SWIG and then
> imported into python again for assembly etc. The compilation happens
> behind the scene so the user do not need to case about it. This seems
> to be a reasonably efficient approach.  What do you do ?

Yes, this seems reasonable. So why is there any need to do it in
SymPy? Is the motivation to be in pure Python? I would like to
understand the motivation better.

As I said, I myself use libmesh for now. Byt the syfi approach is new,
and if you say it speeds things up, well, I am for it. :)

Ondrej

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sympy?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to