Re: [Kwant] [PROVENANCE INTERNET] Re: Should we disable implicit overwriting in Builder?
I'd tend to vote with Anton : until it actually proves dangerous can't we suppose it is safe? I can see many places where it can be very handy to overwrite. For instance is you use a system constructed by someone else and want to see the effect of modifying this and that. ________________________________________ De : Kwant-discuss [kwant-discuss-bounces@kwant-project.org] de la part de GROTH Christoph Envoyé : jeudi 4 février 2016 17:43 À : kwant-discuss@kwant-project.org Objet : [PROVENANCE INTERNET] Re: [Kwant] Should we disable implicit overwriting in Builder? 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
Dear Christoph, Anton and Xavier, I also like to chime in and vote with Anton on this. What I try to do with Kwant is to build nanographene or polycyclic aromatic hydrocarbon (PAH) molecular structures by combining smaller structures/molecules, sometimes in a hierarchical way. With overwrite, when I fuse two benzene rings together I know I’ll get the 10-carbon naphthalene, instead of some 12-carbon beast with overlapping carbon atoms (and their hoppings). This is handy in the sense that it allows me to quickly build up any benzoic (i.e 6-membered rings) PAH molecular structures starting with benzene, say, without ever worrying about overlapped carbon atoms. Another aspect of it is that I usually plot the structure I build and make sure it looks OK, before I do anything with it. Now if we allow overlapped atoms (by default or choice), how would I tell which one it is from the plot (i.e. naphthalene vs. the 12-C structure)? Thanks. Chagaan
On Feb 4, 2016, at 5:26 PM, WAINTAL Xavier <xavier.waintal@cea.fr> wrote:
I'd tend to vote with Anton : until it actually proves dangerous can't we suppose it is safe? I can see many places where it can be very handy to overwrite. For instance is you use a system constructed by someone else and want to see the effect of modifying this and that.
________________________________________ De : Kwant-discuss [kwant-discuss-bounces@kwant-project.org] de la part de GROTH Christoph Envoyé : jeudi 4 février 2016 17:43 À : kwant-discuss@kwant-project.org Objet : [PROVENANCE INTERNET] Re: [Kwant] Should we disable implicit overwriting in Builder?
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
Chagaan Baatar wrote:
I also like to chime in and vote with Anton on this. What I try to do with Kwant is to build nanographene or polycyclic aromatic hydrocarbon (PAH) molecular structures by combining smaller structures/molecules, sometimes in a hierarchical way. With overwrite, when I fuse two benzene rings together I know I’ll get the 10-carbon naphthalene, instead of some 12-carbon beast with overlapping carbon atoms (and their hoppings).
Hi Chagaan, it’s nice to see that you are participating in the discussion! Actually, we have been talking about two things: (1) Whether overwriting existing sites/hoppings of a builder should have a special syntax, so that the current syntax (syst[key] = value) could be reserved for _creating_ new sites/hoppings only. This is the question that I brought up originally. (2) How (and whether) to provide a way in builder to provide multiple values for the same site/hopping. The new low-level systems will allow multiple values for the same site/hopping that will be summed together. This is something that we believe can be useful, and, anyway, it comes naturally with the new format. However, within the current builder, there’s no way to specify an extra value (say, a second value function) for some site/hopping. This is the issue that Anton brought up. As to (1), Anton & Xavier do not like the idea of a special syntax. If I understand them correctly they do not want to solve something that they believe is not a problem. I agree with them that we can wait and see whether the issue that I anticipated ever becomes a problem in practice. Your comment is on (2). I agree with you that if we provide some way to specify additional values for sites and hoppings one has to be careful to preserve the possibility of easily constructing systems. I thought quite a bit about it and I actually wonder now whether it’s really useful to be able to specify multiple values for a single site/hopping on builder level. In a way it’s namely already possible today (and will always be): one can easily make a type that can be used as a builder value and that sums up it’s multiple arguments. It could work like this: syst[a] = Sum(f, g, h) syst[a].append(another_one) Note that this is already possible today, only that Kwant doesn’t provide an implementation of “Sum”. So it’s possible to sum-up multiple values, but with this approach the multiple values will appear as a _single_ one for low-level system. The question is now: do we really need a way to specify multiple low-level system values for the same site/hopping on builder level? I’m not so sure… What do you think? (Note that even if there’s no way to specify multiple values on builder level, the low-level support for multiple values might still be useful. And anyway, as said above, it’s something that comes naturally and it would actually require more effort to disallow it.) Christoph
Thanks for the clarification, Christoph. It's good to know that my molecular structures will not be affected. I was worried about duplicated atoms, when you mentioned disabling overwrite. Now I understand what you really want is a way to automatically combine on-site energies cumulatively (for the same atom), which as you said can be provided with a different function call.
On Feb 8, 2016, at 12:29 PM, Christoph Groth <christoph.groth@cea.fr> wrote:
Chagaan Baatar wrote:
I also like to chime in and vote with Anton on this. What I try to do with Kwant is to build nanographene or polycyclic aromatic hydrocarbon (PAH) molecular structures by combining smaller structures/molecules, sometimes in a hierarchical way. With overwrite, when I fuse two benzene rings together I know I’ll get the 10-carbon naphthalene, instead of some 12-carbon beast with overlapping carbon atoms (and their hoppings).
Hi Chagaan, it’s nice to see that you are participating in the discussion! Actually, we have been talking about two things:
(1) Whether overwriting existing sites/hoppings of a builder should have a special syntax, so that the current syntax (syst[key] = value) could be reserved for _creating_ new sites/hoppings only. This is the question that I brought up originally.
(2) How (and whether) to provide a way in builder to provide multiple values for the same site/hopping. The new low-level systems will allow multiple values for the same site/hopping that will be summed together. This is something that we believe can be useful, and, anyway, it comes naturally with the new format. However, within the current builder, there’s no way to specify an extra value (say, a second value function) for some site/hopping. This is the issue that Anton brought up.
As to (1), Anton & Xavier do not like the idea of a special syntax. If I understand them correctly they do not want to solve something that they believe is not a problem. I agree with them that we can wait and see whether the issue that I anticipated ever becomes a problem in practice.
Your comment is on (2). I agree with you that if we provide some way to specify additional values for sites and hoppings one has to be careful to preserve the possibility of easily constructing systems.
I thought quite a bit about it and I actually wonder now whether it’s really useful to be able to specify multiple values for a single site/hopping on builder level. In a way it’s namely already possible today (and will always be): one can easily make a type that can be used as a builder value and that sums up it’s multiple arguments. It could work like this:
syst[a] = Sum(f, g, h) syst[a].append(another_one)
Note that this is already possible today, only that Kwant doesn’t provide an implementation of “Sum”. So it’s possible to sum-up multiple values, but with this approach the multiple values will appear as a _single_ one for low-level system.
The question is now: do we really need a way to specify multiple low-level system values for the same site/hopping on builder level? I’m not so sure… What do you think?
(Note that even if there’s no way to specify multiple values on builder level, the low-level support for multiple values might still be useful. And anyway, as said above, it’s something that comes naturally and it would actually require more effort to disallow it.)
Christoph
participants (3)
-
Chagaan Baatar
-
Christoph Groth
-
WAINTAL Xavier