Brian, thanks for your input! I will make that Exception baseclass, and raise those NotImplementedErrors. I'll do it the coming weekend.
I really like your idea of implementing the particle/hole stuff on a higher level, and creating algorithms independent of boson/fermi formalism. That is a great suggestion. However, I think it should be done in such a way that the user still has a readily available particle/hole formalism. Let's not sacrifice practical usefulness for programming aesthetics. Right now the above/below fermi checks take care of a mixture of things. At least: 1) Test if two indices have overlapping ranges in the KroneckerDelta implementation + possibly elsewhere (maybe even implicitly!) 2) Normal ordering, contractions 3) Hole/Particle stuff in FermionState 4) Maybe I forget about something I'm curious to how we could leverage the new assumption system to factor out the particle/hole stuff. At least 1) seems like a good candidate for that. I don't think 3) is that important, as the calculations are usually applied to operators, not the states directly. This leaves 2). The algorithms could be made boson/fermion agnostic by implementing normal ordering and contractions as methods of FermionicOperator and BosonicOperator. Then particle/holes would still be low-level, but completely encapsulated in FermionicOperator. What do you think? Øyvind on., 14.10.2009 kl. 12.08 -0700, skrev Brian Granger: > Thanks for putting a github branch up. > > I am crazy busy, but I did glance though things a bit... > > * Can you create a base class for all exceptions in secondquant, like > > class SecondQuantError(Exception): > pass > > and make all other exceptions subclasses of this. > > * Also, what happens if you pass bosonic operators to the new > functions like NO, Wicks. If they don't work for Bosons, they should > raise a NotImplementedError (unless you want to make them work for > Bosons ;-)) > > * It looks like the idea of the fermi surface is built into the > fermion operators and states at the lowest level. I have thought > about this for a few days, and I am not sure this is the best way of > handling it. I realize the using particles and holes is extremely > useful for practical calculations, but... > > There are many situations where you want to work with the fermion > operators, but don't want to think about particles and holes. The > formalism of second quantization for fermions doesn't need to assume > anything about particles and holes. > > Having particles and holes built in to the lowest level of the > fermionic implementation means that we can't easily implement things > like wicks theorem in a general boson/fermion independent manner. > > Do you think it would be possible to implement the fermionic stuff in > a way that didn't assume the particle/hole stuff up front, but that > stuff could be added in a high-level. The situation is similar for > bosons where you have to do tricks to handle the population of the > ground state. > > Cheers, > > Brian > > > > > > > Cheers, > > Brian > > > On Tue, Oct 13, 2009 at 10:58 AM, jegerjensen > <jensen.oyv...@gmail.com> wrote: > > I implemented lots of doctests, and pushed to my new github > account: > > git://github.com/jegerjensen/sympy.git > > There is still some doctests missing, but I think all the > important > stuff is covered. > > Ø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-patches@googlegroups.com To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en -~----------~----~----~----~------~----~------~--~---
