Dear Mr.Granger,
On Mar 28, 10:40 pm, Brian Granger <[email protected]> wrote:
>
> On Thu, Mar 24, 2011 at 6:41 AM, oleksandr gituliar <[email protected]>
> wrote:
> > On Mar 23, 5:31 pm, Brian Granger <[email protected]> wrote:
>
> >> On Wed, Mar 23, 2011 at 12:51 AM, oleksandr gituliar <[email protected]>
> >> wrote:
> >> >> * For QCD related things, I think it would be *very* interesting to
> >> >> implement SU(N), in a similar manner to how we have implemented spin
> >> >> (see sympy.physics.quantum.spin).
>
> >> > Concerning SU(N) representations of the rotation group I agree that it
> >> > would be extremely interesting to work on it especially in a symbolic/
> >> > analytical form. As for the same things in QCD, did you mean Lorentz
> >> > group SU(N) representations (with bispinors, 4-vectors, relativistic
> >> > objects with a higher spin)?
>
> >> I was simply thinking that when doing various types of computations in
> >> QCD, it would be useful for have access to all the SU(N) machinery in
> >> symbolic/numerical form.
>
> > I'm still wondering what do you mean on "SU(N) machinery"?
>
> Generators, commutation/anticommutation relations, structure
> constants, representations as matrices, eigenstates, etc.
>
> Basically everything that is normally done for spin (see
> sympy.physics.quantum.spin).
Those features seems worth to be implemented for Relativistic QM at
first since it is much simpler than any of field theories (ones where
number of states vary via creation/annihilation operators with QED and
QCD among them). Moreover, one needs to re-implement all basic
features for relativistic case (states: 4-vectors, bispinors, etc.,
operators and everything that depends on that) in order to have
"objects" to apply those features to. Personally I'd prefer to have a
particular example of a problem one would like to solve (do you have
one?) and use it as a basis for implementing those features in
contrast to the opposite approach. I guess this task worth a separate
GSoC idea thread and is extremely interesting BTW, however I think
that similar features for non-relativistic case should be completed at
first. What do you think, Mr.Granger?
> > Here [1] I started a new branch in order to refactor existing
> > sympy.physics.quantum module that I hope will be more simpler for the
> > end-user. I'd appreciate to have any suggestions and criticism from
> > you.
>
> This look mostly like things we have implemented already. Also, in
> terms of the Hilbert Space stuff.
More or less. QM formalism was already implemented 100 years ago and
it seems nothing left to work on there from mathematical point of
view. The main challange is to port it to computer systems where
design skills are mainly required in tandem with a solid QM
background.
> We found that for discrete quantum
> systems, the notion of hilbert space was pretty clear. You do run
> into some issues for spaces with symbolic/infinite dimension.
Technically, matrix*vector is substituted by operator*function when N-
>oo limit is considered. I hope that SymPy deals equally well with
both operations (at least it is supposed to). Thus again the issue is
to design a whole interface in a clean and simple way with lots of
examples and docs.
> But for continuous systems (x, p) Hilbert Space is quite complicated
> and to do it right you have to introduce a huge amount of complexity
> with little benefit. Instead of going that route, we have kept it
> simple. What this means is that (just like in real life) the
> HilbertSpaces attached to states and operators are sort of in the
> background. You can ask a state or operator what HilbertSpace it
> belongs to using the .hilbert_space attribute, but the whole approach
> is not very "formal" (which is on purpose).
It looks that currently a Hilbert space is attached somehow
automatically when a state is created, that I think should work an
opposite way round since it has no sense to have a state in some
abstract space with no dimensions. Just try to run:
>>> k1 = Ket('psi')
>>> k1.hilbert_space
H
How many dimensions does H have? That's simple, right:
>>> k1.hilbert_space.dimension
NotImplementedError: This Hilbert space has no dimensions.
Quite unexpected :(
>>> k2 = Ket('phi')
>>> k2.hilbert_space
H
Does k1.hilbert_space == k2.hilbert_space?
>>> k1.hilbert_space == k2.hilbert_space
True
Why is that so, how to make them to be different?
And finally:
>>> k = 3*k1 + 4*k2
>>> type(k)
<class 'sympy.core.add.Add>
Wow, it is supposed to be <class 'sympy.physics.quantum.state.Ket'>,
right?
All those are very simple questions but still very important since
without correctly answering them one will not be able to build more
complicated things like perturbative methods, rotation group
representations (spin and angular momentum).
Summing up, as my GSoC 2011 proposition I'll probably go with an idea
of implementing all those basic features for QM in tandem with
building a solid set of documentation and examples for as many QM
topics as possible (I'll put more details on my wiki page). What do
you think about all that?
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
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.
