In fact, It turned out that the bug in commutator was just a failing
doctest. I thought for a while that ab would always evaluate to True,
and that cmp() was needed. This turned out to be wrong so I reverted
the first commit and just fixed the doctest instead.
Regrettably, I won't have time to
On Mar 30, 2010, at 5:12 AM, jegerjensen wrote:
In fact, It turned out that the bug in commutator was just a failing
doctest. I thought for a while that ab would always evaluate to True,
and that cmp() was needed. This turned out to be wrong so I reverted
the first commit and just fixed the
Øyvind,
I discovered a bug in the canonical ordering of the commutator. It
actually never happened due to a bug in Basic.__gt__ for
noncommutative symbols. These issues are fixed in my branch
'fix__lt__3' on github, and I also pushed my own copy of your quantum
branch and commited a fix
On Mar 27, 6:34 pm, jegerjensen jensen.oyv...@gmail.com wrote:
Another thing: is __repr__() still the recommended way to get nice
printing? There are some closed issues about that, and I got the
impression it should be avoided, but I don't know what should be used
instead...
I think it is
Vinzent,
I played around with this more and by implemeting _sympystr_ and
_sympyrepr_ things behave much better all around. The only other
things that types might want to implement is _pretty_ which will now
be called for the PrettyPrinter. Thanks for the tip though.
Cheers,
Brian
On Sun,
DirectProducts of States are themselves States. This leads to a
diamond inheritance diagram:
Basic---
| |
| |
DirectProduct State
| /
| /
DirectProductState
To me, it
I looked at this last night and it looks like _sympyrepr_ and
_sympystr_ are the recommended ways. In practice _sympystr_ gets used
most of the time. For pretty printing using the pretty function, I am
creating a patch to enable a _pretty_ method. Then things like
|alpha will look right.
I have created a branch on github and have started to implement the
base classes for everything. For now I have been moving things from
secondquant over to a new quantum.py module. In the process I am
striping out all the second quantization stuff and making it
completely general. Lots
On Fri, Mar 26, 2010 at 9:43 AM, Brian Granger ellisonbg@gmail.com wrote:
[...]
DirectProducts of States are themselves States. This leads to a
diamond inheritance diagram:
Basic---
| |
| |
DirectProduct State
|
All,
I have created a branch on github and have started to implement the
base classes for everything. For now I have been moving things from
secondquant over to a new quantum.py module. In the process I am
striping out all the second quantization stuff and making it
completely general. Lots
Thanks Asaf, for introducing us to the openket framework! I also think
this discussion of API is a great initiative, and I have some general
suggestions:
1) The state objects should be responsible for knowing how operators
affect them.
2) Operator objects should only implement their relation to
On 24 Mar, 13:56, Brian Granger ellisonbg@gmail.com wrote:
Øyvind
Thanks for joining in this discussion. Your ideas are definitely more
than welcomed.
1) The state objects should be responsible for knowing how operators
affect them.
2) Operator objects should only implement their
Øyvind,
A|a until you pick a basis. Thus, I almost think the core idea is
that operators and states should know what they themselves look like
in different bases.
Yes! This must be the core idea, and more precisely:
1) States need to know how they look in different bases, i.e. |a and |
On Tue, Mar 9, 2010 at 9:45 AM, Freddie Witherden fred...@witherden.orgwrote:
So far as symbolic manipulation goes I am unsure how useful a GPU (or
similar device) would be. However, the mpmath project may very well be
interested (and is very closely related to SymPy and equally as awesome!).
Well... anything that uses matrices is welcome for CUDA. Also many of
the combinatorial algorithms have parallel versions
On 9 Март, 01:20, Robert Kern robert.k...@gmail.com wrote:
On Mon, Mar 8, 2010 at 17:05, yavor...@mail.bg gerund...@gmail.com wrote:
Hi there, I kind of wanted to
On 9 Mrz., 00:49, Ondrej Certik ond...@certik.cz wrote:
On Mon, Mar 8, 2010 at 3:05 PM, yavor...@mail.bg gerund...@gmail.com wrote:
Hi there, I kind of wanted to participate in this year's GSOC, and I
looked through the suggestions and I couldn't help noticing there are
no suggestions for
16 matches
Mail list logo
