On Wed, May 09, 2012 at 07:03:58AM -0400, James Carman wrote: > On Wed, May 9, 2012 at 3:03 AM, Luc Maisonobe <luc.maison...@free.fr> wrote: > >> Is there such a thing as short-term serialization? > > > > Yes, of course, and this what many people need. This is what James > > called marshalling/unmarshalling. This is a standard way to communicate > > between some applications that share a common basis. Of course [math] is > > not a distributed computing environment, but it should not prevent > > people from being used in a distributed environment. > > > > For long-term serialization needs, I would suggest instead that we > introduce (perhaps it's there already, I'm not familiar with the > entire codebase) exporters/importers [...]
There is some (see e.g. in "o.a.c.m.linear.MatrixUtils"). But even those shows the unfortunate discrepancy between the quality levels of different aspects of the library: While we aim at state-of-the-art implementations of the mathematical algorithms, serialization, among other things, only aims at "good enough for trivial uses" (e.g. the current matrix importer/exporter would probably be useless for sparse matrices). OK, it's there and it could be useful to users of CM, but IMHO we should not push in that direction by adding more and more "sub-par" functionalities. > which support some > industry-standard file format(s) (such as those used by R for > example). I dont' know "R" but nonetheless agree on the "industry-standard". That's not the case currently. The problem we face here, as in other discussions (e.g. monitoring/logging), is the feature/drawback of "no dependencies". My view is that we should be consistent: * either we stick to "no dependencies" and it goes with not introducing anything beyond the core business (that are the math algorithms), or * we provide more facilities for users but those should also be state-of-the-art and thus provided through tools recognized as the best in their category. Regards, Gilles > Now, I would only suggest we introduce these where it makes > sense, such as for larger data structures like matrices. For > something with a few fields, not so much. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
