Do we need to deal w/ 0-based and 1-based matrices?

[billyc]

Cube, Transcad, and Emme all use zone numbers that are 1-based, which is a huge pain in the ass.

How do we want to deal with this? A flag? Ignore it and leave it to the user?

[pschmied]

Just as a thought exercise, imagine a zone system where zones all have
names: ["curly", "moe", "larry"]. The index itself would be a simple
relation:
[("curly", 0),
("moe", 1),
("larry", 2)]

In our 3x3 example, mat["curly"]["larry"] would return the value at
position (0,2). This seems good.

Now, this is where things start to break down. Imagine an index where the
"name" is a integer:
[(1,0),
(2,1),
(3,2)]

mat[0,0] == out of bounds. Ouch.
mat[3,1] == position (2,0). Double ouch.

So, on the one hand, not being prescriptive about zone names seems good. On
the other hand, the temptation for users to name their zones in a patently
confusing off-by-one sort of way seems... bad.

Other thoughts?

On Wed, Jul 31, 2013 at 12:04 PM, Billy Charlton
notifications@github.comwrote:

Cube, Transcad, and Emme all use zone numbers that are 1-based, which is a
huge pain in the ass.

How do we want to deal with this? A flag? Ignore it and leave it to the
user?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4
.

[pschmied]

Oops, that last example is wrong. Should have written mat[0][0]. Y'all knew
what I meant :-)

On Wed, Jul 31, 2013 at 12:22 PM, Peter Schmiedeskamp <peter@thoughtspot.net

wrote:

Just as a thought exercise, imagine a zone system where zones all have
names: ["curly", "moe", "larry"]. The index itself would be a simple
relation:
[("curly", 0),
("moe", 1),
("larry", 2)]

In our 3x3 example, mat["curly"]["larry"] would return the value at
position (0,2). This seems good.

Now, this is where things start to break down. Imagine an index where the
"name" is a integer:
[(1,0),
(2,1),
(3,2)]

mat[0,0] == out of bounds. Ouch.
mat[3,1] == position (2,0). Double ouch.

So, on the one hand, not being prescriptive about zone names seems good.
On the other hand, the temptation for users to name their zones in a
patently confusing off-by-one sort of way seems... bad.

Other thoughts?

On Wed, Jul 31, 2013 at 12:04 PM, Billy Charlton <notifications@github.com

wrote:

Cube, Transcad, and Emme all use zone numbers that are 1-based, which is
a huge pain in the ass.

How do we want to deal with this? A flag? Ignore it and leave it to the
user?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4
.

[billyc]

The new Mapping API handles the case where you have an equivalency list which maps row/column offsets to an index value (e.g. zone number).

I've also hacked ViTables to show the mapping as the row/column header, if one and only one mapping exists.

So maybe this covers the most basic cases.