in simple terms, if non-integer row keying is used anywhere, it tries to rewrite pipelines so that product orientations never require non-int keys to denote columns. In case pipeline makes it impossible, optimizer will refuse to produce a plan.
e.g. suppose A is distributed string-keyed. (A.t %.% A) collect // ok A.t collect // optimizer error val (U, V, s) = dssvd(A) // OK, U keyed same way as A val (U,V) = dals (A) // OK too etc. etc. On Wed, Jun 18, 2014 at 6:02 PM, Dmitriy Lyubimov <dlie...@gmail.com> wrote: > > > > On Wed, Jun 18, 2014 at 5:58 PM, Ted Dunning <ted.dunn...@gmail.com> > wrote: > >> On Wed, Jun 18, 2014 at 5:48 PM, Dmitriy Lyubimov <dlie...@gmail.com> >> wrote: >> >> > > >> > > Or simply that rows and columns are labeled? >> > > >> > rows are labeled. but they have algebraic signficance. >> > >> >> Do they really? >> >> For the in-core system, if I add two matrices with different row labels, >> the row labels are ignored. > > > In-core system has always hard ordinal indexing. The out-of-core system > has only hard ordinal indexing for columns, or rows when they are > int-keyed. > > If I multiply two matrices where the column >> labels of the first matrix are in a different order than the row labels of >> the second, the labels are again ignore. If I do the transpose >> multiplication where the row labels aren't in the same order, again, no >> effect. >> >> Does the DSL actually permute the rows to make operations work correctly? >> > > You'd be surprised :) > >
