Le 09/02/2014 00:40, Thomas Neidhart a écrit : > On 02/08/2014 07:30 PM, Phil Steitz wrote: >> On 2/8/14, 9:25 AM, Thomas Neidhart wrote: >>> Hi, >>> >>> I think we are very close to releasing 3.3. >>> Looking through the issues, the following should/need to be resolved: >>> >>> TN (in progress): >>> >>> * [MATH-1071] Improve genetic algorithms section in userguide >>> * [MATH-1061] Improve filter section in userguide >>> * [MATH-749] Convex Hull algorithm: almost finished >>> >>> Others: >>> >>> * [MATH-1065] EnumeratedRealDistribution.inverseCumulativeProbability >>> >>> should be fixed imho, I outlined an algorithm but would like to have >>> some feedback >> >> See comment on ticket. >>> >>> * [MATH-923] Kohonen's SOFM: can it be considered finished? >> >> You mean releasable :) >> >> +1 - I like this code. The question is really are we OK with the >> API and I don't think we will be able to definitively answer that >> until we get it out and used, so I would say release it now, >> assuming Gilles and others agree. > > me too. > Maybe it is easier to take the risk now as the next foreseen release is > 4.0 and we can more easily correct any mistakes. > >>> * [MATH-928] Alternative approach to matrix implementations: >>> >>> postpone to 4.0? >> +1 >>> >>> * [MATH-990] Improve performance of MathArrays.sortInPlace: >>> >>> finished for 3.3? >> >> +1 >>> >>> >>> Other issues to be discussed: >>> >>> * [MATH-1008] >>> >>> a new package has been created o.a.c.m.fitting.leastsquares which >>> contains some interface for the new fluent API but they are also >>> used elsewhere so I guess it would be more logical to put them in a >>> more general place, e.g. WithMaxEvaluations should be moved to >>> o.a.c.m.optim. WDYT? >> >> +1 >>> >>> * Clirr errors in o.a.c.m.geometry and sub-packages >>> there are now ~30 errors wrt changed interfaces due to some >>> refactoring. What shall we do about them? >> >> Need to decide which are really problems and either revert or doc >> them somehow. > > I think some are harmless (e.g. changed parameter type from Vector to > its superclass Point), but others seem to be not bc.
We have very quickly discussed about it some weeks ago. I have done my best to avoid incompatibilities, and where incompatibilities were unavoidable, there are in fact mostly theoretical. Concerning the parameters changes from Vector to Point, it is in fact false positive from Clirr. The methods signature have been changed at interface level, but the new methods are more general than the previous ones, so at source level, there is still compatibility. At binary level, in fact the former methods are still there with the Vector signature, they have simply been pushed down to implementation level. Therefore, the implementation classes have both signatures available. Concerning the other changes, they correspond to changes at interface level in the partitioning package. Theses interfaces are *not* intended to be implemented by users, and in fact even in the library itself, they have been implemented only by myself, and I have updated all the implementation classes. These interfaces are there *only* as a way to share common code for BSP tree (which is complex code). I would have liked to have them more private, but private inheritance is not allowed in Java. So I really think updating these interfaces even in a minor release is possible, and I explicitly ask for this now. I *need* this and it won't break any real application, as nobody implemented these private interfaces. best regards, Luc > >> I have two other things I would like to get in, but will not hold >> the release up for: >> >> Fix for MATH-984 and first part of MATH-437 (new class and >> deprecations). I have the second thing pretty much done modulo some >> doco cleanup and MATH-984 is straightforward. I am a little pegged >> atm so may miss the boat; but will try to crank through these and >> review other stuff. The new KS class and deprecation I would really >> like to get in because I would like us to remove the existing KS >> class in 4.0. > > I do not want to stress people. If you think it is worth to include it > in 3.3 then we should take the time. Let's also see what Luc still plans > to do / include for the release. > > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
