On 11 March 2013 08:33, Luc Maisonobe <luc.maison...@free.fr> wrote: > Le 11/03/2013 08:51, Luc Maisonobe a écrit : >> Le 11/03/2013 00:47, sebb a écrit : >>> On 10 March 2013 16:35, Luc Maisonobe <luc.maison...@free.fr> wrote: >>>> Le 10/03/2013 15:28, Thomas Neidhart a écrit : >>>>> On 03/04/2013 01:24 PM, Luc Maisonobe wrote: >>>>>> Hi all, >>>>>> >>>>>> I would like to release version 3.2 of [math] soon. >>>>>> Any thoughts about it? >>>>> >>>>> There are 3 Clirr errors: >>>>> >>>>> Error Return type of method 'public int log10()' has been changed to >>>>> org.apache.commons.math3.dfp.Dfp >>>> >>>> I know about this one, it was introduced with r1449529. I have explained >>>> it here: <http://markmail.org/message/2ytqu4qmtkkp5v4z>. >>>> >>>> I would in fact consider this change is merely fixing a bug: the log10 >>>> function returned an int when all other mathematical functions properly >>>> returned a Dfp. The change was two-fold: the log10 method returning an >>>> int was renamed intLog10, and a proper log10 method was added. >>>> >>>> I really don't think anybody will be affected by this change, as the >>>> class itself is probably very seldom used, and most importantly because >>>> despite this weird return type, nobody noticed it and complained about it. >>>> >>>> So I would consider this incompatible change should be accepted, even in >>>> a minor release. >>>> >>> >>> Sorry, I disagree. >>> >>> As far as I can tell, Math 3.1 only included >>> >>> public int log10() >>> public int log10K() >> >> Dfp also had sqrt, reciprocal, and nextAfter with Dfp return types (as >> well as a static copysign with a lower case s and two arguments, not the >> classical non-static with upper case S and one argument). The other >> functions like cos, sin etc also already existed but as static methods >> in DfpMath. >> >>> >>> so it's not entirely surprising that no-one complained about the return >>> type. >>> >>> If it is still decided to ignore the incompatibilty, please document >>> this clearly in the release notes, and ensure log10K() Javadoc states >>> why it has a different return type from all the others. >> >> Yes, I'll do that. > > Maybe I found a way to remove this incompatibility. > > If we remove completely the declaration of log10(), which must return an > instance of T, in the parameterized interface RealFieldElement<T>, then > all implementations may have a different log10 method. This would allow > Dfp to keep its strange return type, at least for the 3.x series, while > DerivativeStructure and Decimal64 can return the proper type. > > Then in 4.0, when we can add incompatible changes, we can add the > declaration back, change Dfp and have all implementations becoming > consistent with respect to this method return type. > > For additional smooth transition for Dfp, we can already add the new > intLog10 method, and deprecate log10 declaring it will change its return > type as of 4.0. > > The only drawback of this hack is that log10 would not be available in > parameterized classes, but only in classes where we already know what T > is, and for which we can directly point to the class implementation and > not the interface specification. > > I'll commit this in a few minutes so the CLIRR report will be ... clear. > Let me know if this does not feel right.
Again, this needs to be very clearly documented, in the release notes as as well as relevant Javadoc please. > Luc > >> >> Luc >> >>> >>>>> >>>>> Error Method 'protected org.apache.commons.math3.FieldElement[][] >>>>> buildArray(org.apache.commons.math3.Field, int, int)' has been removed >>>>> >>>>> Error Method 'protected org.apache.commons.math3.FieldElement[] >>>>> buildArray(org.apache.commons.math3.Field, int)' has been removed >>>>> org.apache.commons.math3.linear.AbstractFieldMatrix >>>> >>>> I missed these ones. The methods have been moved to MathArrays. I'll fix >>>> this by putting them back (deprecated) in AbstractFieldMatrix and set >>>> them up in order to call the methods from MathArrays. >>>> >>>> best regards, >>>> Luc >>>> >>>>> >>>>> Thomas >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>> >>> >> >> >> --------------------------------------------------------------------- >> 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
