Tough call. It's arguably so inefficient as to be thought of as a mild bug. There's also some value in not letting the existing serialization bake in to users' infrastructure for another 6 months. I am not concerned with backward compatibility of this magnitude at this stage, myself.
Therefore if this bit is well-tested, and those tests pass, I say add your change now. On Sun, Oct 17, 2010 at 5:51 AM, Ted Dunning <[email protected]> wrote: > I just noticed that our matrix json serialization has a strangeness in it. > The issue is that a matrix is serialized as an object with two properties. > > The first property is the class name of the actual matrix. > > The second property is the serialized form of the matrix. Unfortunately, > this serialized form is stored as a JSON string rather than a JSON object. > This means that we wind up parsing matrix objects multiple times, first as > the object, then extracting the string, parsing that, then possibly > extracting rows as objects which contain strings which must be parsed. > JSON > parsing is fast, but this is perverse. > > I am happy to fix this along with all tests that break (shouldn't be any). > I would very much like to fix this for 0.4, but it could wait. > > Is there anybody who depends on archival storage of JSON serialized > matrices > or vectors? I think I can make the format backward compatible, but would > still like to know. >
