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()

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. 


> 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.

Reply via email to