Debugging DiracDelta integration and next steps in representations

 

This week has been pretty eventful, though not much code itself has been written. In Illinois we had some storms early in the week which knocked out my internet for a few days…but now I’m back and up and running.

I mentioned in my last post that I found a bug in the integration of DiracDelta functions. I had my first branch of GSoC merged into sympy with a fix for this, but then found out that the tests that I had written for it were failing in master for some other users! The problem that I fixed was that the when going through a Mul with multiple DiracDeltas, deltaintegrate would only keep the last one it found and completely throw out the rest. Instead, I had it collapse the first one it found with the integrated variable in it, and keep the rest with the appropriate subsitutions. This comes from the identity that

If has other delta functions inside of it, the identity still applies!

The problem with my fix turned out to be a sorting issue! The test that I had written was tailored for the results on my computer, but the args of the Mul were being sorted differently on others’ computers so that the test ended up failing. I then opened another pull request with code that used sympy’s default_sort_key in deltaintegrate to make sure all the arguments of the Mul were sorted the same way before the function was integrated, and that fixed the issue!

In addition to that, I was able to touch base with my mentor Brian Granger and he gave me some good suggestions on changes to make to my existing code and also some new directions to take in representing continuous bases. I think these will lay good groundwork for starting to actually implement multiple coordinate systems and the canonical quantum systems (particle in a box, harmonic oscillator, etc.). These changes include:

1. Rather than having an API to get the basis kets of an operator, it makes more sense to have an API to get the basis operators of a given ket. This is because in higher dimensions, position kets are actually simultaneous eigenkets of multiple operators. To this end, there will be a global function which can map between states and sets of operators, or vice versa.
2. In addition to this, rather than just taking an operator class as the specification for a basis in represent, represent will now be able to take three things as inputs for the basis: a single operator, a set of operators, or a state. It will then use the global function to map between them.
3. The default labeling systems needs to be revamped with states with multiple labels in mind. It makes more sense to define it as something like “default_args” and have it always return a tuple. More tests with time-dependent states will also help make sure this is clear

I have also been starting to think about how to handle implementing the various coordinate systems that will need to be done. It might make sense to have a general Position type class, which can then me called to have a request coordinate set returned. This needs to be fleshed out a bit more though. First, I will work on making the changes Brian suggested and submit my first big GSoC pull request.