Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Labels should always be strings, never ints #50

Closed
goerz opened this issue Mar 18, 2017 · 1 comment
Closed

Labels should always be strings, never ints #50

goerz opened this issue Mar 18, 2017 · 1 comment

Comments

@goerz
Copy link
Member

goerz commented Mar 18, 2017

Using integers as labels e.g. for BasisKet should not be allowed (or rather, an integer label should be converted via str in the __init__ routine). Allowing integers makes it tempting to do arithmetic on the labels. However, any code that does this will fail if the labels are actually strings! Instead, numerical indices should be obtained via an index method / property

@goerz
Copy link
Member Author

goerz commented Mar 18, 2017

Actually, there are reasons for supporting both numeric indices and string labels: For numeric indices, we can do a number of operations without having to specify the basis (or dimension) of the underlying Hilbert space. For example, we can apply a Creation operator.

However, we need a strict and explicit interface for handling this: BasisKet can be instantiated with a label_or_index parameter. If this parameter is an int, it is taken as the index, if it is a string, as the label. Add an index property which is different from the label property (always a string!)

@goerz goerz closed this as completed in 3d85c17 Mar 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant