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