[aerosayan]

In C++ I created a custom matrix struct, that allows column order/row order access, allows fortran like halo cell layers, and currently I'm thinking if I should provide support for 1 indexed access, as most matrix formulas are easier to write in 1 indexed form.

Thus, translating the mathematical formulas to code becomes quite easy when we use 1 indexed access. Fortran supports really good support for 1 indexed access, and I think it's better than 0 indexed access in C++. But, due to historical reasons C++ uses 0 indexed access.

Performance wise, the index access formula needs to be updated to be : index = ecols*(icol-1)+(irow-1);

The additional subtractions -1 might be an issue later on, but currently the compiler seems to be smart enough to automatically optimize the subtractions away.

Not sure which one should I choose.
Which one do you prefer? 0 or 1 indexed access?

[sbaffini]

0-indexing in C/C++ makes a lot of sense when you look at it from the C side, as stride from original pointer address. I mean, everything different would even sound out of place.

But when you look at it from an array perspective, excluding few cases that are only relevant algorithmically, 1 is really the only relevant choice in my opinion.

But the point, I think, is more about who is coding than anything else.

[aerosayan]

Yeah it becomes complicated, if we have matrices or vectors with different explicit lower bounds (as in fortran), The developers can use 0 indexed access too, as we can just select the offset while creating the object, like vector<float, 0> vec;

So using 1 might be better for now.

'constexpr if' in C++17 will be useful for defining access rules based on the given offset at compile time. Though I'm not sure on what will be the performance impact when we use multiple matrices at once. Compiler seems to optimize well for simple equations.

Ehhh ... if performance is bad, I'll fix it later. I will create a multigrid accelerated poisson solver to test out if the performance is good or bad.

[LuckyTran]

0 makes sense from a programming and memory access and coding perspective. But if math and structures are involved, always 1. In other words, I understand why languages support indexing start at 0, but please let it start at 1.

[Continuum]

... an interesting subject for sure. I started in Fortran and that defaulted to a 1's based indexing. Moving to C, C++, Matlab, Python, Powerbasic, MathCAD etc., these are 0's based.



For your consideration: https://docs.oracle.com/cd/E19957-01.../z400091044d0/


Initially I struggled with this a bit, but now it is the standard. Of course, several of these can also be shifted back to a 1's based indexing.



Anyway, I find I like to call out for loops with a 1's base, e.g. 1 to N, but then index x[i-1]. For me, that is more readable.


Regards

[flotus1]

I use 4 spaces, fight me!
Oh wait, wrong topic

[LuckyTran]

Originally Posted by Continuum

Moving to C, C++, Matlab, Python, Powerbasic, MathCAD etc., these are 0's based.

Matlab starts at 1 btw. Coincidence that the (not an actual programming language) language dedicated to matrix manipulations doesn't natively support zero indexing except as a null pointer...? Oh and matlab probably never will support zero indexing.

[FMDenaro]

My opinion (as an old Fortran user) is that one should first focus on the meaning of the matrix.

If we are storing a matrix of a linear system, I would use only the standard algebric notation of 1.

On the other hand, we often use arrays to store the unknown variables using a topology with the grid location. Now there is no meaning associated to an algebric system and I am used to adopt any bound values I need.

[sbaffini]

Originally Posted by flotus1

I use 4 spaces, fight me!
Oh wait, wrong topic

At the stake!!!

[praveen]

1-based is good for computational work. Fortran has the best of all since it allows you to change the indexing, even negative indexing, which is great for writing pde solvers.

Some languages like Python make it confusing in some case. If you do

for i in range(1,n):

i never takes the value n !!! I find this more of a problem than zero indexing.

Whereas many other languages behave in a more natural way

do i=1,n  (fortran)
for i=1:n (matlab, julia)

all take values from 1 to n including n.

[Continuum]

Originally Posted by LuckyTran

Matlab starts at 1 btw.

You are right. I was less right.

[Gerry Kan]

I am raised in the school of C, so I automatically start thinking with indices beginning with 0. As far as numbers go, this is the only number I am willing to hard code, particularly for loops.

Although for me much less preferred, I also extend this thinking to languages where the array index begins with 1 (Fortran, wink wink).

What I have problem with is explicit ranges that Fortran allows. I don't know why this feature is there (presumably to attain better interoperability with zero-based arrays, say, from MPI) but your code will get out of hand in no time, having to need to keep track which limits apply to which array

Worst still, passing said array as an argument will revert this into a 1 to N basis unless you explicitly set these bounds again in the declaration, which means extra arguments brought in as parameters or arguments.

Gerry.

[sbaffini]

Originally Posted by Gerry Kan

Worst still, passing said array as an argument will revert this into a 1 to N basis unless you explicitly set these bounds again in the declaration, which means extra arguments brought in as parameters or arguments.
Gerry.

Not discussing the rest, but if said subroutine is in a module, declaring the input array as allocatable, i.e.,

integer, allocatable, intent(in) :: array( : , : )

then ubound and lbound will return the proper values.

[Gerry Kan]

Originally Posted by sbaffini

if said subroutine is in a module, declaring the input array as allocatable, i.e.,

integer, allocatable, intent(in) :: array( : , : )

then ubound and lbound will return the proper values.

I see that too, but if this array is being passed around as a subroutine argument, it starts overs from 1 to N again ...