You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2013/10/29 15:00:26 UTC
[Math] Deprecate "pow(int, long)" and "pow(long,long)" in
"ArithmeticUtils"
Hello.
While working on MATH-1047, I wondered about the usefulness of those
two methods. Excluding the trivial case (base=|1|), the result will
overflow as soon as the exponent is larger than 31, when base=|2|,
and sooner the larger the base.
Hence, the methods amount to syntactic sugar to spare a cast from
a "long" to an "int" exponent.
IMO, this is not worth the number of source code lines.
Unless there is an objection, I propose to deprecate those methods
in 3.3 and remove them in 4.0.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Deprecate "pow(int, long)" and "pow(long,long)" in "ArithmeticUtils"
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 29/10/2013 23:04, Gilles a écrit :
> On Tue, 29 Oct 2013 20:14:19 +0100, Luc Maisonobe wrote:
>> Le 29/10/2013 15:00, Gilles a écrit :
>>> Hello.
>>
>> Hi Gilles,
>>
>>>
>>> While working on MATH-1047, I wondered about the usefulness of those
>>> two methods. Excluding the trivial case (base=|1|), the result will
>>> overflow as soon as the exponent is larger than 31, when base=|2|,
>>> and sooner the larger the base.
>>> Hence, the methods amount to syntactic sugar to spare a cast from
>>> a "long" to an "int" exponent.
>>> IMO, this is not worth the number of source code lines.
>>> Unless there is an objection, I propose to deprecate those methods
>>> in 3.3 and remove them in 4.0.
>>
>> There were three main reasons for this method :
>>
>> - in many cases, very low (and fixed) exponents are often encountered
>> (say exponents up to half a dozen or so),
>> - computation with long in Java bytecode is not done the same way as
>> int because it needs two successive variable slots and requires
>> successive memory loading, and thus is slower (of course, this effect
>> disappears when the JIT compiler converts everything to native code
>> if the processor is 64 bits),
>> - forcing the user to add a cast clutters the code.
>>
>> As always, your mileage may vary.
>>
>
> I must be missing something (sorry!): I propose to remove the methods were
> the exponent is a "long", and as I understand it, you give reasons for
> doing
> so:
Sorry, I misread the subject. I thought you wanted to remove the
pow(int,int) and preserve only pow(long,long).
> 1. Why would one want/need to use a "long" for a _small_ value?
> 2. Moreover you say that using a "long" is slower; thus, a second reason
> for
> not calling those methods.
> 3. A cast would only be necessary if the user chooses to use a "long"
> anyway,
> even if it is neither necessary (cf 1.) nor desirable (cf. 2.).
Go ahead with removing the long exponent.
Luc
>
> Best,
> Gilles
>
>
> ---------------------------------------------------------------------
> 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
Re: [Math] Deprecate "pow(int, long)" and "pow(long,long)" in
"ArithmeticUtils"
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 29 Oct 2013 20:14:19 +0100, Luc Maisonobe wrote:
> Le 29/10/2013 15:00, Gilles a écrit :
>> Hello.
>
> Hi Gilles,
>
>>
>> While working on MATH-1047, I wondered about the usefulness of those
>> two methods. Excluding the trivial case (base=|1|), the result will
>> overflow as soon as the exponent is larger than 31, when base=|2|,
>> and sooner the larger the base.
>> Hence, the methods amount to syntactic sugar to spare a cast from
>> a "long" to an "int" exponent.
>> IMO, this is not worth the number of source code lines.
>> Unless there is an objection, I propose to deprecate those methods
>> in 3.3 and remove them in 4.0.
>
> There were three main reasons for this method :
>
> - in many cases, very low (and fixed) exponents are often
> encountered
> (say exponents up to half a dozen or so),
> - computation with long in Java bytecode is not done the same way as
> int because it needs two successive variable slots and requires
> successive memory loading, and thus is slower (of course, this
> effect
> disappears when the JIT compiler converts everything to native
> code
> if the processor is 64 bits),
> - forcing the user to add a cast clutters the code.
>
> As always, your mileage may vary.
>
I must be missing something (sorry!): I propose to remove the methods
were
the exponent is a "long", and as I understand it, you give reasons for
doing
so:
1. Why would one want/need to use a "long" for a _small_ value?
2. Moreover you say that using a "long" is slower; thus, a second
reason for
not calling those methods.
3. A cast would only be necessary if the user chooses to use a "long"
anyway,
even if it is neither necessary (cf 1.) nor desirable (cf. 2.).
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Deprecate "pow(int, long)" and "pow(long,long)" in "ArithmeticUtils"
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 29/10/2013 15:00, Gilles a écrit :
> Hello.
Hi Gilles,
>
> While working on MATH-1047, I wondered about the usefulness of those
> two methods. Excluding the trivial case (base=|1|), the result will
> overflow as soon as the exponent is larger than 31, when base=|2|,
> and sooner the larger the base.
> Hence, the methods amount to syntactic sugar to spare a cast from
> a "long" to an "int" exponent.
> IMO, this is not worth the number of source code lines.
> Unless there is an objection, I propose to deprecate those methods
> in 3.3 and remove them in 4.0.
There were three main reasons for this method :
- in many cases, very low (and fixed) exponents are often encountered
(say exponents up to half a dozen or so),
- computation with long in Java bytecode is not done the same way as
int because it needs two successive variable slots and requires
successive memory loading, and thus is slower (of course, this effect
disappears when the JIT compiler converts everything to native code
if the processor is 64 bits),
- forcing the user to add a cast clutters the code.
As always, your mileage may vary.
best regards,
Luc
>
>
> Regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> 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