On Mon, Jul 19, 2010 at 12:57 PM, Ronan Lamy <ronan.l...@gmail.com> wrote:
> Le samedi 17 juillet 2010 à 12:26 -0700, Matt Curry a écrit :
>> Okay, I really like the idea of factory functions and a single State
>> class because (to the best of my knowledge) someone could do something
>> like:
>>
>> >>> ket = Ket('beta')
>> >>> ket
>> |beta>
>>
>> The Ket factory function would hand State the name as well as ket=True
>> and return a State instance or something like that. I think this would
>> be important for any kind of basic to midrange user's intuition
>> (rather than just knowing what dictionary keys to pass to State).
>
> Obviously, any reasonable solution has to behave as you stipulate in an
> interactive session. But I don't see why this would imply that kets and
> bras should be amalgamated into a single class. For me, kets and bras
> are objects of different kinds and therefore require separate classes.
> With the single class option, you'll be forced to write code like:
>
> if bra_or_ket.is_ket:
>    do_something()
> elif bra_or_ket.is_bra:
>    do_something_else()
> else:
>    raise HelpMeIMLost()

But right now we already have that type of logic all over, but it uses
isinstance instead.

> BTW, I have a problem with your terminology: "kets" are "states" (aka
> "wavevectors" aka plain old "vectors"), so I find it a bit confusing to
> use synonymous names for distinct concepts.

In my mind the state of a quantum system is any mathematical entity
that contains all the information about the system.  In this sense,
both a bra and a ket are the state as they contain equivalent
information.  From the OO design perspective, the Bra and Ket classes
hare most of their methods and attributes, hence the common base
class.  But I will admit that not everyone uses the terms in this
manner.

At this point, we are going to leave Bra and Ket and their own classes
and see how it goes.

Cheers,

Brian

>
>> On Jul 17, 4:11 am, Øyvind Jensen <jensen.oyv...@gmail.com> wrote:
>> > fr., 16.07.2010 kl. 13.25 -0700, skrev Brian Granger:
>> >
>> >
>> >
>> >
>> >
>> > > Hi,
>> >
>> > > Currently in secondquant and quantum we are making Bra and Ket
>> > > subclasses of State:
>> >
>> > > class State(Expr):
>> > > class Bra(State):
>> > > class Ket(State):
>> >
>> > > the other option would be to make the ket/bra-ness an option:
>> >
>> > > bra = State('alpha', bra=True)
>> >
>> > > The advantage of this approach is that things like dagger can
>> > > automatically know how to build the bra or ket from the ket or bra,
>> > > without having to know what the appropriate class is.  Also, the
>> > > inheritance diagram for states is getting to be pretty messy when we
>> > > introduce TensorProducts and this keeps it simple.  We could still
>> > > have Bra/Ket factory functions that build State instances with the
>> > > right options.  Thoughts?
>> >
>> > I don't see any problems with the approach you suggest, but your
>> > question inspired me to think a bit about dual states.
>> >
>> > Another approach entirely is to consider bra states as *operators*, and
>> > not states at all.  I've seen some texts treating bras as operators
>> > mapping kets to the complex plane (as opposed to the usual operators
>> > mapping kets to kets.).  I don't know exactly where that would lead with
>> > respect to a Sympy implementation, but it could be worth to consider it.
>> > I don't have strong opinions about this, I just wanted to share my
>> > thoughts.
>> >
>> > Cheers,
>> >
>> > Øyvind
>> >
>> >
>> >
>> >
>> >
>> > > Brian
>> >
>> > > --
>> > > Brian E. Granger, Ph.D.
>> > > Assistant Professor of Physics
>> > > Cal Poly State University, San Luis Obispo
>> > > bgran...@calpoly.edu
>> > > elliso...@gmail.com
>>
>
>
> --
> 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+unsubscr...@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
bgran...@calpoly.edu
elliso...@gmail.com

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Reply via email to