I just pushed some of the trivial fixes to github, please pull. Ondrej, I fixed the 'str' variable as well.
Øyvind On 15 Okt, 18:54, Brian Granger <ellisonbg....@gmail.com> wrote: > On Thu, Oct 15, 2009 at 2:26 AM, Øyvind Jensen <jensen.oyv...@gmail.com>wrote: > > > > > > > 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? > > I think I would love to think about this more today but I have a big > deadline at 5 pm ;-) > > I will try to get back to this F, Sat or Sun. > > Cheers, > > Brian > > > Ø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 -~----------~----~----~----~------~----~------~--~---
