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.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.
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-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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
