to., 01.07.2010 kl. 12.28 -0500, skrev Brian Granger:
> On Tue, Jun 29, 2010 at 5:10 PM, Øyvind Jensen <jensen.oyv...@gmail.com>
> wrote:
> > ti., 29.06.2010 kl. 11.26 -0700, skrev Matt Curry:
> >> Hello,
> >>
> >> I've been working on implementing Hilbert spaces in SymPy. I have
> >> created/improved two files located on my github account:
> >>
> >> hilbert.py:
> >> http://github.com/mattcurry/sympy/blob/hilbert/sympy/physics/hilbert.py
> >> test_hilbert.py:
> >> http://github.com/mattcurry/sympy/blob/hilbert/sympy/physics/tests/test_hilbert.py
> >>
> >> They are rebased and ready to go; please review them to see if
> >> anything needs to be changed.
> >>
> >> Thanks,
> >>
> >> Matt Curry
> >>
> >
> > Hello Matt,
> >
> > I just had a quick glance, and I think it looks very good! I'll see if
> > I can find time to review it properly tomorrow. I've got two questions
> > already, though:
> >
> > 1) Do you really need to overload _eval_subs(old, new)? As far as I can
> > see, your implementations do not differ from what you should get by just
> > leaving it to Basic._eval_subs().
>
> I think you are right, but Matt should check this with tests.
>
> > 2) (A more general question) What is the plan for how the framework will
> > be used in practical calculations? Specifically, have you figured out
> > what will be the relation between the hilbert spaces and the elements
> > that populate them? Lets say you have a 1-d function representing the
> > ground state of a square well, how will you connect that function with
> > your framework? Inheritance?, aggregation?, assumptions? etc.
>
> The main thing that hilbert spaces will allow is for different
> operations to make sure that elements belong the the right hilbert
> space. For examples, to do operator application, inner products,
> etc., we need to make sure the underlying hilbert spaces are
> compatible. That is the main purpose of having them. Most of that
> will be done using HilbertSpace.__contains__.
This will be very useful!
>
> > I am asking because I am implementing an Indexed class as part of my
> > project, and eventually I'd like them to interact with your framework.
> > If that works out, we can generate all kinds of QM equations in an
> > abstract matrix representation.
>
> What will the indexed class do and how does it differ from
> sympy.Matrix? Matt is about to start working on representation
> theory, so it might be good to keep you in the loop.
>
Yes, keep me in the loop! this is exciting :-)
In contrast to sympy.Matrix, the Indexed class will let you work
elementwise on abstract objects with unknown dimensions. For instance
you can express a matrix-vector product as:
In [1]: from sympy.tensor import Indexed, Idx
In [2]: a = symbols('a')
In [3]: A = Indexed(a)
In [4]: X = Indexed(x)
In [5]: A(k, m)*X(m)
Out[5]: a(k, m)⋅x(m)
where k,m,x were defined by isympy and the summation over m is implicit.
The dimensions were not specifed here, but you can also use symbols to
specify the range of each index.
The motivation for me right now is the possibility to generate code that
perform calculations on arrays with a lot of flexibility. But I try to
keep the Indexed and Idx classes as general as possible, so that they
can be specialized and reused in other contexts. For QM, the
possibility to represent vectors and matrices with infinite dimension
may be useful.
The current code is here:
http://github.com/jegerjensen/sympy/blob/fortran_codegen4/sympy/tensor/indexed.py
http://github.com/jegerjensen/sympy/blob/fortran_codegen4/sympy/tensor/tests/test_indexed.py
Øyvind
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to this group, send email to sympy-patc...@googlegroups.com.
To unsubscribe from this group, send email to
sympy-patches+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy-patches?hl=en.
