commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [Math] Serializable (again)
Date Sat, 12 May 2012 14:49:53 GMT
Hi all,

Le 09/05/2012 13:41, Gilles Sadowski a écrit :
> On Wed, May 09, 2012 at 07:03:58AM -0400, James Carman wrote:
>> On Wed, May 9, 2012 at 3:03 AM, Luc Maisonobe <> 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.

I have tried to set up a clean serialization process for the classes
that needs it, starting with the PointValuePair class as requested in

It turns out several previous choices completely prevent this to be done.

At the beginning, we had a PointCostPair (created when the mantissa
library was imported in 2006), which was then renamed
ScalarPointValuePair in 2009, then RealPointValuePair a few days later
until 2012 (see
This class was made serializable as of r748274 (2009-02-26,

This class was renamed PointValuePair and changed to extend
Pair<double[], Double> as of r1243186 on 2012-02-12. At that time, it
lost is serializble feature since base class Pair is not serializable.
The problem is that it is now impossible to add this feature back
because Pair<K,V> also misses a no-arg constructor (which is fine
because it must be immutable and we cannot enforce K and V to be

This problem of Pair serialization was already encountered a few months
ago (see discussion <>, were
a SerializablePair class was mentioned). The SerializablePair class was
created as of r1079545 (2011-03-11,
<>) and
deleted 16 days later as of r1086045 according to MATH-551 (2011-03-27,

In order to fix bug MATH-787 and to recover the lost functionality of
serializing the simple containers similar to PointValuePair, I would
suggest we drop the inheritance from Pair<K,V> (because we *cannot*
enforce serialization for this base class dur to its generic nature). We
do not need this inheritance to Pair<K,V> here. It brings no added value
to the class. Droping this inheritance would allow a clean and simple
implementation of serialization. However, I fear this is an incompatible
change (we cannot cast anymore to Pair).

What do you think about it ?


> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message