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/PugetSoundRegionalCouncil/omx/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/PugetSoundRegionalCouncil/omx/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.