GSoC 2011 - Oleksandr Gituliar
oleksandr gituliar
my name is Oleksandr Gituliar and I'm a second year PhD student at The
Institute
of Nuclear Physics [1] in Krakow, Poland.
As a physicist I mainly deal with theoretical calculations in QCD
(namely, next-
to-leading order corrections to solutions of DGLAP evolution equation
and all
stuff related to that like Feynman graphs, regularization techniques,
factorization
theorems, etc.) as well as Monte-Carlo simulations of different kind.
As a programmer I'm involved in a freelance activity [2] as well as my
personal
opensource mini projects [3] and [4]. I'm mainly programming in Python
and C/C++,
however also familiar with Scheme.
A more detailed list of projects proposals will follow soon as a wiki
page, but
briefly I can say that physics projects as well as symbolic
mathematics are under
my consideration.
PS. Sending this letter I express my strong interest in participating
in GSoC 2011.
[1] http://www.ifj.edu.pl
[2] http://www.odesk.com/users/Python-and-programmer-theoretical-physicist-see-http-gituliar_~~39097b1ddefc549a
[3] https://bitbucket.org/gituliar
[4] http://hg.tx97.net/gituliar/krkmc/summary
Brian Granger
Welcome,
> my name is Oleksandr Gituliar and I'm a second year PhD student at The
> Institute
> of Nuclear Physics [1] in Krakow, Poland.
>
> As a physicist I mainly deal with theoretical calculations in QCD
> (namely, next-
> to-leading order corrections to solutions of DGLAP evolution equation
> and all
> stuff related to that like Feynman graphs, regularization techniques,
> factorization
> theorems, etc.) as well as Monte-Carlo simulations of different kind.
Nice, your experience could be very helpful.
> As a programmer I'm involved in a freelance activity [2] as well as my
> personal
> opensource mini projects [3] and [4]. I'm mainly programming in Python
> and C/C++,
> however also familiar with Scheme.
>
> A more detailed list of projects proposals will follow soon as a wiki
> page, but
> briefly I can say that physics projects as well as symbolic
> mathematics are under
> my consideration.
>
> PS. Sending this letter I express my strong interest in participating
> in GSoC 2011.
Here is what I suggest:
* have a look at the ideas page on github (see recent threads for the link).
* 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).
* There are a number of other topics, such as second quantization that
you may be intersted in.
* I highly recommend digging into the code ASAP and starting to
contribute before the application deadline.
* Don't hesitate to ask questions!
Cheers,
Brian
> [1] http://www.ifj.edu.pl
> [2] http://www.odesk.com/users/Python-and-programmer-theoretical-physicist-see-http-gituliar_~~39097b1ddefc549a
> [3] https://bitbucket.org/gituliar
> [4] http://hg.tx97.net/gituliar/krkmc/summary
>
> --
> 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+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgra...@calpoly.edu
elli...@gmail.com
oleksandr gituliar
> > Institute
> > of Nuclear Physics [1] in Krakow, Poland.
>
> > As a physicist I mainly deal with theoretical calculations in QCD
> > (namely, next-
> > to-leading order corrections to solutions of DGLAP evolution equation
> > and all
> > stuff related to that like Feynman graphs, regularization techniques,
> > factorization
> > theorems, etc.) as well as Monte-Carlo simulations of different kind.
>
> Nice, your experience could be very helpful.
> > PS. Sending this letter I express my strong interest in participating
> > in GSoC 2011.
>
> Here is what I suggest:
>
> * have a look at the ideas page on github (see recent threads for the link).
> * 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).
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 highly recommend digging into the code ASAP and starting to
> contribute before the application deadline.
> * Don't hesitate to ask questions!
PS. I'll let you know once I finish working on my idea list.
Sincerely,
Oleksandr.
oleksandr gituliar
not complete and is supposed to be constantly updated. Feel free to
make any corrections and/or proposals.
[1] https://github.com/sympy/sympy/wiki/GsoC-2011-Application-Oleksandr-Gituliar
Brian Granger
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 had a look at your ideas page. A few comments:
* Under the "basic QM notation" section. I think everything listed
there has already been implemented, at least initially. Definitely
have a look at the code for that. But there is definitely more to do,
especially with continuous Hilbert spaces with differential operators.
* Perturbation theory + variational methods. I would love to see a
lot of detail here as we would very much be interested in this topic.
Cheers,
Brian
>> * I highly recommend digging into the code ASAP and starting to
>> contribute before the application deadline.
>> * Don't hesitate to ask questions!
>
> Surely!
>
> PS. I'll let you know once I finish working on my idea list.
>
> Sincerely,
> Oleksandr.
>
oleksandr gituliar
> On Wed, Mar 23, 2011 at 12:51 AM, oleksandr gituliar <gitul...@gmail.com> 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.
As for calculations in QCD, they are heavily based on Feynman graphs
and very specific techniques (like regularization, renormalization,
Monte-Carlo, and others depending on what one is looking for). Anyway
that field looks interesting for a very narrow community, comparing
for example to QM. Thus I think the latter would have more interest
from people and is interesting enough to play with it in both
educational and practical directions.
> I had a look at your ideas page.
> A few comments:
>
> * Under the "basic QM notation" section. I think everything listed
> there has already been implemented, at least initially. Definitely
> have a look at the code for that. But there is definitely more to do,
> especially with continuous Hilbert spaces with differential operators.
great, however, as you mentioned, is quite raw in a sense of
communication between different objects. A luck of application
examples is another drawback.
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.
> * Perturbation theory + variational methods. I would love to see a
> lot of detail here as we would very much be interested in this topic.
[1] https://github.com/gituliar/sympy/commit/5bcda815b12b98eacbb38811ddffef000571a8fd
oleksandr gituliar
> On 03/23/2011 06:23 AM, oleksandr gituliar wrote:> Here [1] I started a wiki page with my ideas and proposals. Note it is
> > not complete and is supposed to be constantly updated. Feel free to
> > make any corrections and/or proposals.
>
> If you are interested in SO(n) the attached paper might interest you.
>
> 302KViewDownload
However this article seems more theoretical than aimed for practical
use, it could help. Thank you.
Brian Granger
On Thu, Mar 24, 2011 at 6:41 AM, oleksandr gituliar <gitu...@gmail.com> wrote:
> On Mar 23, 5:31 pm, Brian Granger <elliso...@gmail.com> wrote:
>>
>> On Wed, Mar 23, 2011 at 12:51 AM, oleksandr gituliar <gitul...@gmail.com> 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).
> As for calculations in QCD, they are heavily based on Feynman graphs
> and very specific techniques (like regularization, renormalization,
> Monte-Carlo, and others depending on what one is looking for). Anyway
> that field looks interesting for a very narrow community, comparing
> for example to QM. Thus I think the latter would have more interest
> from people and is interesting enough to play with it in both
> educational and practical directions.
>
>> I had a look at your ideas page.
>
> Great, thank you.
>
>> A few comments:
>>
>> * Under the "basic QM notation" section. I think everything listed
>> there has already been implemented, at least initially. Definitely
>> have a look at the code for that. But there is definitely more to do,
>> especially with continuous Hilbert spaces with differential operators.
>
> I constantly digging into it... It covers a lot of topics, that is
> great, however, as you mentioned, is quite raw in a sense of
> communication between different objects. A luck of application
> examples is another drawback.
Yes, feel free to ask lots of questions as you dig in.
> 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. 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.
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).
Cheers,
Brian
>> * Perturbation theory + variational methods. I would love to see a
>> lot of detail here as we would very much be interested in this topic.
>
> Surely, I'll let you know once I add more details.
>
> [1] https://github.com/gituliar/sympy/commit/5bcda815b12b98eacbb38811ddffef000571a8fd
>
> --
> 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+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
oleksandr gituliar
On Mar 28, 10:40 pm, Brian Granger <elliso...@gmail.com> wrote:
> On Thu, Mar 24, 2011 at 6:41 AM, oleksandr gituliar <gitul...@gmail.com> wrote:
> > On Mar 23, 5:31 pm, Brian Granger <elliso...@gmail.com> wrote:
>
> >> On Wed, Mar 23, 2011 at 12:51 AM, oleksandr gituliar <gitul...@gmail.com> 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).
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.
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.
>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).
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?
Alan Bromborsky
at the end is the Dirac equation using the geometric algebra formalism.
Brian Granger
I don't do anything with SU(N) for N>2 myself, but I thought that your
or others would find it useful. If not, that is fine as well. But, I
don't think you would have to implement all the fancy stuff like
4-vectors, bispinors, etc. Just like to implement spin, we didn't
have to implement spinors. From the abstract quantum perspective,
there are simply states that can be represented in different bases.
Sure, those states may have fancy transformation properties, but to
talk about the states, you don't need that.
>> > 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.
This is an important point. Currently sympy does not have the notion
of differentialoperator*function. This is why representation logic
currently does not work with continuous hilbert spaces. See
sympy.physics.quantum.represent for the current logic.
>> 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 :(
Actually, given the fact that you don't know what hilbert space the
ket belongs to (it is completely abstract), this *is* the expected
result. Teaching states and operators about their hilbert spaces and
other details is handled by subclasses Ket, Bra, Operator. See
sympy.physics.quantum.spin for details and examples.
> >>> 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?
Again, subclassing.
> 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?
Nope, sympy represents everything using expression trees. Just add to
Symbols together and you will also get an Add, not another symbol.
The same is true of anything abstract in sympy.
>
> 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).
Please spend more time with the code. We spent the last year thinking
about these questions in great depth. I agree with you that these are
important questions, but at this point, I think we have mostly
answered them in our current implementation. I apologize that are
documentation is lacking, but the code, doctests and test are pretty
organized and will answer most of your questions.
> 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?
I think if you propose to do something that 1) is already implemented
in sympy and/or 2) only involves documentation the proposal will not
be very successful. I would also revisit the list of topics related
to quantum that are on the sympy ideas wiki page.
Cheers,
Brian