Switching from 0-based to 1-based indexing scheme

[bassoy]

Currently tensor and subtensor types support 0-based in indexing, see example.

C.at(0,0) = std::conj(B.at(0,1));

I propose to switch from zero-based to one-based indexing with multi-indices.
This style is akin to Matlab, Octave and R (all one-based) but different than in NumPy (zero-based).

C.at(1,1) = std::conj(B.at(1,2));

[yimyom]

I'm in favor or 1-indexing too. Interestingly I always found 0-indexing awkward in vector, matrix and tensor objects, for the simple reason that the first column or row should be called one and not zero. At the same time, I always found strange not to use a 0-indexing in arrays. I think Pascal was using a 1-indexing if I remember correctly. Anyway, indexing in an array represent an offset or a distance if you prefer from the first address in memory to the element we want to reach. Therefore 0 makes sense in this context. I fully support 1-indexing in ublas

…

On Thu, Oct 21, 2021 at 5:44 PM Cem Bassoy ***@***.***> wrote: Currently tensor and subtensor types support 0-based in indexing, see example <https://github.com/boostorg/ublas/blob/develop/examples/tensor/access_tensor.cpp> . C.at(0,0) = std::conj(B.at(0,1)); I propose to switch from zero-based to one-based indexing with multi-indices. This style is akin to Matlab, Octave and R (all one-based) but different than in NumPy (zero-based). C.at(1,1) = std::conj(B.at(1,2)); — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#140>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQOK4BCIZL6GEJL5U3TZA3UH6ZFFANCNFSM5GNKUROQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[bassoy]

And we could still use zero-based indexing for the operator[] e.g.

for(auto i = 0u; i < A.size(); ++i)
  A[i] = 1;

So we have the best of both worlds.

[penguian]

Will this be a backwards-compatible change, or will it break all existing code?

[bassoy]

We distinguish between the tensor extension (which will have new matrix/vector types) and (legacy) matrix/vector types which will be deprecated but still usable.

For the new tensor extension, it would break existing code.

[bassoy]

@penguian would that cause problems for your programs?

[penguian]

My programs (Glucat and Pyclical) use matrices and 0-based indexing. As long as matrices remain unchanged the programs will not see any problems. Pyclical is a C++ extension module for Python, written using Cython. Python and Python packages also use 0-based indexing, including for tensors, (e.g. https://deeplearninguniversity.com/pytorch/pytorch-tensor-indexing/)

[campreilly]

I really dislike the proposal to goto 1-indexing. The uBLAS library is just one tiny little cog in the vast machine of Boost C++ libraries, and not a universe of its own. It may be confusing for people coming from other languages, but reversing this would be just as confusing for people whose core mission is building C++ applications. Someone might suggest supporting BOTH, but in my 35 years of experience, those are the worst kind of software architecture decisions in the long run. Sean Reilly On Oct 25, 2021, at 3:32 AM, Cem Bassoy ***@***.***> wrote:  We distinguish between the tensor extension (which will have new matrix/vector types) and (legacy) matrix/vector types which will be deprecated but still usable. For the new tensor extension, it would break existing code. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[bassoy]

The uBLAS library is just one tiny little cog in the vast machine of Boost C++ libraries, and not a universe of its own.

Boost is a collection of C++ library. Most libraries are unique in the sense that they provides a convenient application-specific interfaces for their users. Maintainers and contributors of each library can make their own choices which in general is discussed openly mostly on the boost mailing list. So a discussion about breaking interface changes is quite valid and sometimes necessary.

It may be confusing for people coming from other languages, but reversing this would be just as confusing for people whose core mission is building C++ applications.

Hard to argue for or against this statement as we don't know the numbers. I assume that the majority of C++ programmers are clever enough to use one-based indexing. Also to give a background information: we are introducing new tensor types with new addressing modes. So there is almost no backward compatibility issue here for the tensor type. Yet, in the long run we might use the tensor type for matrix and vector types.

Someone might suggest supporting BOTH, but in my 35 years of experience, those are the worst kind of software architecture decisions in the long run.

As software and requirements change over time, how would you introduce API changes? Would you always break APIs?

[yimyom]

if we have 1-indexing, we must have it everywhere in tensor, not just for .at(). Otherwise it will be very confusing and prone to bugs. We can't do half and half and hope to only capture the best of both worlds.

…

On Mon, Oct 25, 2021 at 6:34 PM Cem Bassoy ***@***.***> wrote: And we could still use zero-based indexing for the operator[] e.g. for(auto i = 0u; i < A.size(); ++i) A[i] = 1; So we have the best of both worlds. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#140 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQOK4FRAQWGAEB7344OAQ3UIUCARANCNFSM5GNKUROQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[yimyom]

I must admit that on second thought, Sean has a point here. C++ developers will use uBlas as a primary library and not as a conversion tool from Matlab or R. Thinking about it, Rcpp in R uses a 0-indexing for vectors and matrices, while R itself uses 1-indexing. On Mon, Oct 25, 2021 at 11:10 PM Sean Reilly ***@***.***> wrote:

…

I really dislike the proposal to goto 1-indexing. The uBLAS library is just one tiny little cog in the vast machine of Boost C++ libraries, and not a universe of its own. It may be confusing for people coming from other languages, but reversing this would be just as confusing for people whose core mission is building C++ applications. Someone might suggest supporting BOTH, but in my 35 years of experience, those are the worst kind of software architecture decisions in the long run. Sean Reilly On Oct 25, 2021, at 3:32 AM, Cem Bassoy ***@***.***> wrote:  We distinguish between the tensor extension (which will have new matrix/vector types) and (legacy) matrix/vector types which will be deprecated but still usable. For the new tensor extension, it would break existing code. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQOK4F3SYZR3N3QRNND65LUIVCLJANCNFSM5GNKUROQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.