Description: Cell and range properties and methods should be one based (1) not zero based (0). When counting things in that exist in the physical world the first item is 1, not 0. Whether it be marbles or rows and columns. For example .getCellByPosition(1,1) ' Should return A1 (first row and column) not B2 (second row and column) .getCellRangeByName("A1").CellAddress.Row ' Should return 1 (first row), not 0 .getCellRangeByName("A1").CellAddress.Column ' Should return 1 (first column), not 0 Steps to Reproduce: 1.Self evident in description 2. 3. Actual Results: Self evident in description Expected Results: Self evident in description Reproducible: Always User Profile Reset: No Additional Info: Cell and range properties and methods should be one based (1) not zero based (0). When counting things in that exist in the physical world the first item is 1, not 0. Whether it be marbles or rows and columns. For example .getCellByPosition(1,1) ' Should return A1 (first row and column) not B2 (second row and column) .getCellRangeByName("A1").CellAddress.Row ' Should return 1 (first row), not 0 .getCellRangeByName("A1").CellAddress.Column ' Should return 1 (first column), not 0
Unfortunately this cannot be changed. It would break all Calc macros in existence. Also, in most programming languages arrays and matrices are indexed starting at zero. My take: WF
A "Row_Column_Base" option would be similar to the already existing "Base" option that sets the default base {0|1} for arrays and would not break any existing macros. The default behavior would remain 0 base. Just like it does for the array base option. There is a direct correlation to the spreadsheet rows and columns labeling in the physical real world here. The spreadsheet rows and columns functions follow this direct correlation with using one (1) base. Using zero (0) base in macros to reference spreadsheet rows and columns is inconsistent with the spreadsheet functions and creates confusion, error and extra effort in development and troubleshooting. When there is a direct correlation to a physical world counted item, such as spreadsheet rows an columns, a one (1) base is appropriate and easier for humans to work with. Computer applications are tools of humans and as such they should accommodate humans, rather than humans accommodating computer applications. The argument that it has always been done that way or is done that way elsewhere is weak status quo prevention of change for the betterment. Please implement a rows columns base option. It won't hurt. Thanks
I think adding complexity to it with more options is not desirable. This is a scripting/programming language, and can be expected to count zero-based. "Won't fix" for me too.
(In reply to Stéphane Guillou (stragu) from comment #3) > I think adding complexity to it with more options is not desirable. This is > a scripting/programming language, and can be expected to count zero-based. > "Won't fix" for me too. In fact reduces complexity for the coder/users. Zero base is inconsistent with spreadsheet columns & rows labeling and corresponding functions that are 1 (one) based. Nothing changes unless the coder intentionally sets the option. A scripting/programing language can be expected to have options to facilitate humans. That's purpose of scripting/programming languages. A one base option is much better, clearer and human friendlier than having to add 1 to zero based column & row indexes. Especially when there is a 1 (one) based array option. Add the same type of option for columns & rows indexes and eliminate the here we add 1 and here we don't. That is complexity for the coder/users. If you you or anyone doesn't what to use the option. You don't have to. Won't affect you one bit.
(In reply to NOYB from comment #0) > When counting things in that exist in the physical world the first item is > 1, not 0. But it does not in IT, see https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html (and many other articles)