Matrices as a datatype

[jpolitz]

For graphics (e.g. seam-carving), pagerank-like algorithms, etc, it would be useful to have a matrix or spreadsheet-like datatype.

[blerner]

So would 1-d arrays...
Providing matrix operations as a built-in library would be quite
nice, and given that +/-/* all desugar to method calls you could
even get operator overloading for them. But writing that library can
be done easily in Pyret, once you have fast 1/2/n-dimensional array
accesses.On 6/13/2013 9:40 AM, Joe Politz wrote:

  For graphics (e.g. seam-carving), pagerank-like algorithms,
    etc, it would be useful to have a matrix or spreadsheet-like
    datatype.
  —
    Reply to this email directly or view
      it on GitHub.

[shriram]

Also useful for tasks like collaborative filtering (think Netflix
challenge).

Spreadsheets are slightly different from matrices, in that I'd like the
user to even be able to type the labels of the rows and columns, and can
perhaps even use them for addressing the elements. (But the spreadsheets
will not be reactive, ie, raw data, no formulas and other active content.)

[dbp]

I'd vote for implementing matrices not with arrays, but rather
hashtables. In most real applications, matrices are both very big and very
sparse. Having memory usage proportional to the non-sparse entries vs the
whole domain is really nice. Phil Klein has pedagogical matrix/vector
implementations in python that are essentially dictionaries mapping tuples
to field elements (used in 53), and it works really well, because python
has the operator to method call desugaring.

But, we should still have arrays.

On Thu, Jun 13, 2013 at 11:03 AM, Shriram Krishnamurthi <
notifications@github.com> wrote:

Also useful for tasks like collaborative filtering (think Netflix
challenge).

Spreadsheets are slightly different from matrices, in that I'd like the
user to even be able to type the labels of the rows and columns, and can
perhaps even use them for addressing the elements. (But the spreadsheets
will not be reactive, ie, raw data, no formulas and other active content.)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/32#issuecomment-19397680
.

[blerner]

That sounds like it's arguing for traits, then, so you can have both
sparse and dense implementations that nevertheless expose Matrix
operations...  ;-)On 6/13/2013 7:05 PM, Daniel Patterson
  wrote:
I'd vote for implementing matrices _not_ with arrays,
  but rather

  hashtables. In most real applications, matrices are both very big
  and very

  sparse. Having memory usage proportional to the non-sparse entries
  vs the

  whole domain is really nice. Phil Klein has pedagogical
  matrix/vector

  implementations in python that are essentially dictionaries
  mapping tuples

  to field elements (used in 53), and it works really well, because
  python

  has the operator to method call desugaring.

  But, we should still have arrays.

  On Thu, Jun 13, 2013 at 11:03 AM, Shriram Krishnamurthi <
  notifications@github.com> wrote:

  > Also useful for tasks like collaborative filtering (think
  Netflix

  > challenge).

  >

  > Spreadsheets are slightly different from matrices, in that
  I'd like the

  > user to even be able to type the labels of the rows and
  columns, and can

  > perhaps even use them for addressing the elements. (But the
  spreadsheets

  > will not be reactive, ie, raw data, no formulas and other
  active content.)

  >

  > —

  > Reply to this email directly or view it on

GitHubhttps://github.com//issues/32#issuecomment-19397680
> .

  >
  —
    Reply to this email directly or view
      it on GitHub.

[schanzer]

For documentation's sake, there's an old PR for this: #688

[schanzer]

Now that we have tabular data, is this still something we want?

[blerner]

Matrices != tables. There's still a use for this as a library (and there's an initial, fairly complete implementation already), but we need to decide how we want the operators to behave in it and whether we want to use methods or functions, etc.

[shriram]

Echoing that matrices ≠ tables, so that's not a reason to close.