Should we disable implicit overwriting in Builder?
Dear Kwant users,
Right now it is possible to overwrite bits of a builder, i.e.:
syst[lat(0, 0)] = 1 # Create a new site. syst[lat(0, 1)] = 1 # Create another site. syst[lat(0, 0)] = 2 # Overwrite the first site.
Kwant builders behave like this because they are mimicking Python’s dictionaries. I wonder, however, whether this behavior is not both mostly useless and a bit dangerous, especially when a symmetry is involved. It will only get worse when Builder will understand other symmetries (e.g. rotational).
What if Builder instances would not allow items to be overwritten when using the above syntax? (There would be a special method that provides the current behavior – it could be called “reset” or “overwrite”).
I think that most Kwant scripts would not be affected by this behavior. If anyone every blindly assumes that a builder allows overwriting, the error message will quickly point out the problem and mention the “overwrite” method, so the potential for confusion seems very low.
I do not intend to do this (backwards-incompatible) change right away. I’m just curious to hear whether anyone thinks that it’s a bad idea.
Cheers, Christoph
Hi Christoph,
Firstly, overwriting hoppings is handy, and we even use it in Kwant tutorial: http://kwant-project.org/doc/1/tutorial/tutorial2#nontrivial-shapes
Second aspect of the problem I wanted to mention is that we anyway discussed that the new low level system format would allow to associate more than a single value with a site or a hopping. That change would require a corresponding modification of the builder interface, however not sure in which fashion.
Best, Anton
On Wed, Feb 3, 2016 at 5:19 PM, Christoph Groth christoph.groth@cea.fr wrote:
Dear Kwant users,
Right now it is possible to overwrite bits of a builder, i.e.:
syst[lat(0, 0)] = 1 # Create a new site. syst[lat(0, 1)] = 1 # Create another site. syst[lat(0, 0)] = 2 # Overwrite the first site.
Kwant builders behave like this because they are mimicking Python’s dictionaries. I wonder, however, whether this behavior is not both mostly useless and a bit dangerous, especially when a symmetry is involved. It will only get worse when Builder will understand other symmetries (e.g. rotational).
What if Builder instances would not allow items to be overwritten when using the above syntax? (There would be a special method that provides the current behavior – it could be called “reset” or “overwrite”).
I think that most Kwant scripts would not be affected by this behavior. If anyone every blindly assumes that a builder allows overwriting, the error message will quickly point out the problem and mention the “overwrite” method, so the potential for confusion seems very low.
I do not intend to do this (backwards-incompatible) change right away. I’m just curious to hear whether anyone thinks that it’s a bad idea.
Cheers, Christoph
Anton Akhmerov wrote:
Firstly, overwriting hoppings is handy, and we even use it in Kwant tutorial: http://kwant-project.org/doc/1/tutorial/tutorial2#nontrivial-shapes
Sure it is handy. That’s why I don’t want to disallow it, only to make it explicit in order to avoid things getting overwritten by accident. The relevant line in the tutorial would become something like:
sys.rewrite(hops_across_cut, hopping_phase)
One could argue that this is more explicit, though perhaps a bit ugly. The question is whether the gain in security outweighs the loss in simplicity. I think it could, especially with complex symmetries.
Second aspect of the problem I wanted to mention is that we anyway discussed that the new low level system format would allow to associate more than a single value with a site or a hopping. That change would require a corresponding modification of the builder interface, however not sure in which fashion.
I actually encountered this problem today with Mathieu when we were writing a routine to wrap-around some hoppings (due to limitations of current Kwant low-level systems).
An updated builder could behave (always?) as a mapping of sequences of values, perhaps similar to a collections.defaultdict(list). Then, adding a new value would work like this:
sys[key].append(value)
or
sys[key] += [value]
We could still accept values that are not sequences, so that sys[key] = number/function would be possible. But that might be problematic since matrices are sequences, too.
I think a sequence is better than a set since it doesn’t leave the order of addition undefined. The order of addition doesn’t matter algebraically, but numerically it does.
The above looks a bit unmathematical, but it has the advantage of being consistent with the rest of Python. One could also make
sys[key] += value
work, but that would necessitate twisting the semantics in rather ugly ways:
sys[key] = value assert sys[key] is value # This would fail.
What do you think? (Comments by people outside of the Kwant team are especially welcome!)
Christoph
participants (2)
-
Anton Akhmerov -
Christoph Groth