commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <...@spaceroots.org>
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 <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.

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

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
<http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/RealPointValuePair.java?view=log&pathrev=1243185>).
This class was made serializable as of r748274 (2009-02-26,
<http://svn.apache.org/viewvc/commons/proper/math/trunk/src/java/org/apache/commons/math/optimization/PointValuePair.java?r1=748274&r2=746504&pathrev=748274>).

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
serializable).

This problem of Pair serialization was already encountered a few months
ago (see discussion <http://markmail.org/thread/7fghomgsvayplhmb>, were
a SerializablePair class was mentioned). The SerializablePair class was
created as of r1079545 (2011-03-11,
<http://svn.apache.org/viewvc?view=revision&revision=1079545>) and
deleted 16 days later as of r1086045 according to MATH-551 (2011-03-27,
<http://svn.apache.org/viewvc?view=revision&revision=1086045>).

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 ?

Luc

> 
> 
> 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
> 
> 


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


Mime
View raw message