Re:Coda, a “next-generation spreadsheet” – from rows and col...
by kamaal on Wednesday October 25, 2017 @07:37AM
(#15549216)
I discussed this in this same thread. If your formulas are using values from from other cells, it makes sense to name them explicitly.
'TaxRate' makes more sense then 'Pick the value from the same row, three columns to the left'
Re:Coda, a “next-generation spreadsheet” – from rows and col...
by masklinn on Wednesday October 25, 2017 @07:46AM
(#15549249)
> I discussed this in this same thread. If your formulas are using values from from other cells, it makes sense to name them explicitly.
Surely if you're not "using values from other cells" you don't need cell references at all, and then what do you care about A1 versus R1C1?
Re:Coda, a “next-generation spreadsheet” – from rows and col...
by kamaal on Wednesday October 25, 2017 @11:17PM
(#15556107)
If you are building a non-trivial application you will end up using value generated in one cell, in another.
Its exactly like programming. A lot of state is stored in intermediate variables.
Well an obvious reason is R1C1 clearly spells out which is the row and which is the column and further makes it very clear when you're using absolute addressing (RYCX) or relative (R[±Y]C[±X]).
But that's not what I'm talking about in the previous comment. What I'm saying is that A1 is implicitly relative: open excel or google spreadsheet, type "=A1" in a cell, then copy/paste it to an other cell, it won't be "=A1" anymore it'll be offset by the difference between the source and destination cell and thus may have become e.g. "=C8". To fix that you have to "lock in" the dimensions by prefixing them with $ e.g. $A$1 does not move around at all, $A1 does not move in the column but may move in the row and A$1 does not move in the row but may move in the column. R1C1 does not have that issue, as a user you spell out explicitly whether you want absolute or relative addressing (in either dimension) and the software keeps thing exactly as specified.