I see what you mean.

To repeat in other words, the problems that need to be solved are:

a) there are many uses already so adding attributes should be transparent to
those who don't use them

b) the encoding should not be ad hoc because this would be our second ad hoc
encoding and only one should ever be allowed before using a standard

So here is a (kind of) concrete proposal:

a) use JSON or Thrift for concrete syntax

b) design the encoding so that it can carry matrix/vector type information
(dense/sparse, float/double) as a matrix level attribute

c) have the main array be serialized as a map of row number to (list of cell
data) for dense formats or as map of row number to (list of column numbers,
list of corresponding cell data) for sparse matrices

d) serialize vectors as a list of cell data for dense formats or list of
column numbers, list of cell data for  sparse matrices

e) optionally include attribute maps at the matrix, row, column and cell
level (for matrices) or at the vector or cell level (for vectors).


The thing I don't like about this is that it seems nicer if the matrix is a
row map of vectors.  Doing that cleanly and still maintaining column level
attributes seems hard to do economically.

Thoughts?

On Sun, Oct 19, 2008 at 8:05 AM, Jeff Eastman <[EMAIL PROTECTED]>wrote:

> .. move them all to a uniform serialization/deserialization approach.




> ... about 70 references to the asFormatString and asWritableComparable that
> need to be checked so this is not a trivial change.
>
> We should discuss the alternative techniques (Java Serializable, XML, JSON,
> ...) and make this change before implementing element labels. That was where
> I ran out of steam, though I seem to have more now :).
>
>

Reply via email to