commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [Math] Serializable (again)
Date Wed, 09 May 2012 11:41:51 GMT
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.Maisonobe@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message