Hilbert Space Review
Matt Curry
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
Øyvind Jensen
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().
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.
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.
Cheers,
Øyvind
Øyvind Jensen
________________________________________________________________________________
______ /home/oy/git_workingdir/sympy/sympy/physics/tests/
test_hilbert.py _______
File "/home/oy/git_workingdir/sympy/sympy/physics/tests/
test_hilbert.py", line 1, in <module>
from sympy.physics.hilbert import l2, L2, FockSpace,
TensorProductHilbertSpace, DirectSumHilbertSpace,
DirectPowerHilbertSpace
File "/home/oy/git_workingdir/sympy/sympy/physics/hilbert.py", line
267
obj = Expr.__new__(cls, *args, commutative=False)
^
SyntaxError: invalid syntax
________________________________________________________________________________
__ sympy/utilities/tests/
test_code_quality.py:test_whitespace_and_exceptions ___
File "/home/oy/git_workingdir/sympy/sympy/utilities/tests/
test_code_quality.py", line 97, in test_whitespace_and_exceptions
check_directory_tree(SYMPY_PATH, test, exclude)
File "/home/oy/git_workingdir/sympy/sympy/utilities/tests/
test_code_quality.py", line 58, in check_directory_tree
file_check(fname)
File "/home/oy/git_workingdir/sympy/sympy/utilities/tests/
test_code_quality.py", line 78, in test
assert False, message_space % (fname, idx+1)
AssertionError: File contains trailing whitespace: /home/oy/
git_workingdir/sympy/sympy/physics/hilbert.py, line 233.
________________________________________________________________________________
_______ sympy/utilities/tests/
test_code_quality.py:test_implicit_imports _______
File "/home/oy/git_workingdir/sympy/sympy/utilities/tests/
test_code_quality.py", line 121, in test_implicit_imports
check_directory_tree(SYMPY_PATH, test, exclude)
File "/home/oy/git_workingdir/sympy/sympy/utilities/tests/
test_code_quality.py", line 58, in check_directory_tree
file_check(fname)
File "/home/oy/git_workingdir/sympy/sympy/utilities/tests/
test_code_quality.py", line 110, in test
assert False, message_implicit % (fname, idx+1)
AssertionError: File contains an implicit import: /home/oy/
git_workingdir/sympy/sympy/physics/hilbert.py, line 76.
Øyvind Jensen
> File "/home/oy/git_workingdir/sympy/sympy/physics/hilbert.py", line
> 267
> obj = Expr.__new__(cls, *args, commutative=False)
> ^
> SyntaxError: invalid syntax
line is compatible with 2.5:
obj = Expr.__new__(cls, *args, **{'commutative': False})
There are 3 places in the file where this needs to be changed.
Matt Curry
sooner. I'm taking care of the things you're mentioning (I was really
oblivious to some of the errors). I'll get back to you in more detail
in a bit.
Matt
Matt Curry
to github.
1) I removed all of the subs lines. I realized they didn't need to be
overwritten!
2) Whatever can live in a Hilbert space will have a .hilbert_space
attribute that can be compared when necessary.
I'll get back to you on DirectSumHilbertSpace being commutative. And
I'll fix other issues that arise (they seem to come up pretty fast).
Matt
On Jun 29, 3: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
Øyvind Jensen
> Okay, I've fixed up a few more things you've mentioned and pushed it
> to github.
Cool. I just finished commenting on github
http://github.com/mattcurry/sympy/commit/8e63d9d62bcadddd475bcd6e6ee711e166cb6fbe
In general it looks very good: It's well documented, the coding style
follows the standard and the tests are extensive. The comments I made
are mainly suggestions that may or may not be valid.
> 2) Whatever can live in a Hilbert space will have a .hilbert_space
> attribute that can be compared when necessary.
I noticed the __contains__ method. Very nice!
Cheers,
Øyvind
Øyvind Jensen
> Okay, I've fixed up a few more things you've mentioned and pushed it
> to github.
Øyvind
Brian Granger
> 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__.
> 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.
Cheers,
Brian
> Cheers,
>
> Ø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-...@googlegroups.com.
> To unsubscribe from this group, send email to sympy-patche...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
>
>
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgra...@calpoly.edu
elli...@gmail.com
Øyvind Jensen
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
Brian Granger
Yes, I definitely will.
> 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)
OK, this example helps me to understand the goal..
> 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.
That would be very useful.
> 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.
Yep. I just got back from SciPy and I talked a lot with one of the
devs of theano:
http://deeplearning.net/software/theano/
Are you familiar with this? It looks quite impressive and does code
generation for both CPUs and GPUs. They actually have a lightweight
symbolic engine and they were interested in seeing if they could use
sympy instead. It is definitely worst looking at. I can contact them
if you want to explore this further.
> 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
Thanks!
Brian
Øyvind Jensen
> Yep. I just got back from SciPy and I talked a lot with one of the
> devs of theano:
>
> http://deeplearning.net/software/theano/
Thanks for bringing theano to my attention!
>
> Are you familiar with this? It looks quite impressive and does code
> generation for both CPUs and GPUs. They actually have a lightweight
> symbolic engine and they were interested in seeing if they could use
> sympy instead. It is definitely worst looking at. I can contact them
> if you want to explore this further.
>
Theano looks very nice, especially the GPU functionality is cool. I
will play with it and see what I can learn from it. However, they use
expression trees that are different from ours, so I fear it will be
nontrivial to use it directly with sympy. Whereas our tree consist of
operations and operands, they have Apply-nodes that contain an operation
instance and the operands. I wonder how much their optimization
framework depend on the form of the theano expression tree.
Øyvind
Ronan Lamy
> > Yep. I just got back from SciPy and I talked a lot with one of the
> > devs of theano:
> >
> > http://deeplearning.net/software/theano/
>
> Thanks for bringing theano to my attention!
Yes, that's very interesting!
> > Are you familiar with this? It looks quite impressive and does code
> > generation for both CPUs and GPUs. They actually have a lightweight
> > symbolic engine and they were interested in seeing if they could use
> > sympy instead. It is definitely worst looking at. I can contact them
> > if you want to explore this further.
> >
>
> Theano looks very nice, especially the GPU functionality is cool. I
> will play with it and see what I can learn from it. However, they use
> expression trees that are different from ours, so I fear it will be
> nontrivial to use it directly with sympy. Whereas our tree consist of
> operations and operands, they have Apply-nodes that contain an operation
> instance and the operands. I wonder how much their optimization
> framework depend on the form of the theano expression tree.
Theirs is the obviously correct way of dealing with mathematical
functions in a CAS, but sympy will get there in the end (that's issue
1688). In the mean time, there's an obvious bijection between f(x, y, z)
and Apply(f, (x, y, z)) so this doesn't seem to be a difficult problem.
On the other hand, theano uses types and variables, which sympy doesn't
have: I think this is a more significant barrier to translating between
the two.
In any case, merging the two code bases seems a useful and achievable
medium-term goal.
Ronan
Brian Granger
I talked to James, one of the Theano devs, and I think it wouldn't be
too difficult to use Sympy for the top level stuff, because of the
bijection between the two data structures. In terms of the types, my
idea was to use the assumptions system.
> In any case, merging the two code bases seems a useful and achievable
> medium-term goal.
Definitely.
Cheers,
Brian
> Ronan
Aaron S. Meurer
I see the reasons for using an Apply for functions like f(x), but is there a good reason to add such an extra layer to the core Mul/Add/Pow? To me, it just seems like an extra layer that is already solved by class polymorphism. Or am I missing some fundamental aspect of it that can't be solved so easily with the current model like there are for f(x) described for issue 1688?
Aaron Meurer
Ondrej Certik
I agree with Aaron. For functionals, you can just use symbols instead
of functions and use some substitution at the end.
But maybe, if things are done properly, there is a place for it.
Ondrej