Thanks for your swift responses, I've got some comments: > * In various places you use the variable "str." This is dangerous as > str is a builtin type (a string).
Absolutely, It should be substituted immediately. > * It is a little awkward to have the occupation #'s stored differently > for bosons and fermion. For bosons > it looks like you store the list of occupation #'s (dense format) but > for fermions, the indices of occupied states > (sparse format). Did you do this for performance/algorithmic reasons? > For states with a few particles but many states the sparse > structure of your fermionic approach would be better, but as the > number of particles approaches the number > of states, I think the sparse format doesn't give any advantage. I am > wondering if we can use the same > storage format for both bosons and fermions. Sparse for both? Dense > for both? The Bosonic classes still have dense format because I didn't want to mess around too much with the implementation. Also, I am not overly familiar with Bosonic physics, so I am not sure if there could be disadvantages with a sparse format in the Bosonic case. The reason I chose the sparse format for the Fermionic case was not because of storage considerations. Rather because I wanted to treat problems without depending on the number of particles and the size of the model space. I believe the framework will be much more flexible if we can avoid specifying the fermi level. Actually, the fermion state objects are somewhat redundant. You can derive all equations using Wicks theorem on a Mul of SqOperators. (Like it is done in the coupled cluster example.) The Fermion states are implemented just for convenience. This may sound a bit stupid, but I have to admit that I never used those classes (FKet, FBra) myself, except when writing tests for them. Maybe the Fermion States should simply be wiped out? About Assumptions: As Ondrej pointed out, I used the old assumption system. I am aware that it must be replaced, but I didn't want to rely on the new system before it reaches a final form. Ondrej wrote: > ...the new assumption system doesn't store the assumptions within the > symbols. One could use global assumptions, > or remember them locally in the instance though and the new system > should allow to create new assumptions easily. > > Why not to store this information in the FermionicOperator(SqOperator) > instance itself? (And not use assumptions at all?) The information about above/below fermi does not actually apply to the operator itself, rather to the index. The FermionicOperator constructor could extract information from the symbol and store it, but somehow the information must be connected to the Symbol object. I guess that implies global assumptions. It could be possible to generalize the KroneckeDelta implementation this way. Maybe KroneckerDelta(a,b) could simply rely on the global assumptions to determine if anything certain can be said about a==b or a!=b. The current implementation is inconveniently specialized to the Fermionic Operator framework. Cheers Ø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 -~----------~----~----~----~------~----~------~--~---
