commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [math] releasing 3.2?
Date Mon, 11 Mar 2013 13:50:40 GMT
On 11 March 2013 08:33, Luc Maisonobe <Luc.Maisonobe@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.Maisonobe@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-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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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