view.view Indices Start at 0

[hotmeme]

xyz indices start at 1.
When you use view.view on a program output and set show_indices to True, it shows the indices for each atom starting at 0.
This causes the displayed indices of each atom to be off by 1 and is super misleading if viewers don't catch that it starts at 0.

[hotmeme]

These incorrect indices are also used for the distance method of Structure. People will likely measure the wrong distance as a consequence.

[coltonbh]

As discussed, software zero-indexes (starts counting from 0). The first element of an array (e.g., an array of atomic symbols or geometry coordinates) will always be 0. Many end user programs not intended for software engineers remedy this for users in the UI by providing an interface that starts counting from 1 (like we all learned in grade school).

In the case of qcio there are tradeoffs between keeping things simple as a software package (zero-index everything) and trying to provide end user interfaces that match what appears to be common behavior in some QC programs (i.e., to start counting from 1 instead of 0).

We could probably have an option to make the view.view function optionally display values as 1-indexed if the end users wants (e.g., view.view(..., one_index=True). But we'd need to be clear that this is just for display convenience. If you make any modifications to these data structures in python code you'd need to use python-code compatible zero-indexing.