commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amey Jadiye <ameyjad...@gmail.com>
Subject Re: [NUMBERS] Proposal for refactoring and extension of Gamma functions.
Date Tue, 06 Jun 2017 19:45:01 GMT
Hi,

Gamma class is written keeping in mind that it should handle fair situation
(if n < 20) it computes with normal gamma function else it uses
LanczosApproximation
for higher numbers, for now I think we should keep it behaviour as it is
and do just code segrigation, by segregation of there functionalities  we
are making it switchable so Gamma class by optional providing constructor
args of Lanzoz, Stinling or Spouge's algo, same thing we have to do in
Math's Gamma distribution.

Ex.
Gamma g = Gamma(Algo.LANCZOS));

I'd like other people from group chime in discussion.

Regards,
Amey

On Tue, Jun 6, 2017 at 3:31 AM, Gilles <gilles@harfang.homelinux.org> wrote:

> On Tue, 6 Jun 2017 01:14:38 +0530, Amey Jadiye wrote:
>
>> Hi All,
>>
>> Coming from discussion happened here
>> https://issues.apache.org/jira/browse/NUMBERS-38
>>
>> As Gamma is nothing but advanced factorial function gamma(n)=(n-1)! with
>> advantages like we can have factorial of whole numbers as well as
>> factional. Now as [Gamma functions (
>> https://en.wikipedia.org/wiki/Gamma_function ) which is having general
>> formula {{Gamma( x ) = integral( t^(x-1) e^(-t), t = 0 .. infinity)}} is a
>> plane old base function however Lanczos approximation / Stirling's
>> approximation /Spouge's Approximation  *is a* gamma function so they
>> should
>> be extend Gamma.
>>
>> Exact algorithm and formulas here :
>>  - Lanczo's Approximation -
>> https://en.wikipedia.org/wiki/Lanczos_approximation
>>  - Stirling's Approximation  -
>> https://en.wikipedia.org/wiki/Stirling%27s_approximation
>>  - Spouge's Approximation -
>> https://en.wikipedia.org/wiki/Spouge%27s_approximation
>>
>> Why to refactor code is because basic gamma function computes not so
>> accurate/precision values so someone who need quick computation without
>> precision can choose it, while someone who need precision overs cost of
>> performance (Lanczos approximation is accurate so its slow takes more cpu
>> cycle) can choose which algorithm they want.
>>
>> for some scientific application all values should be computed with great
>> precision, with out Gamma class no choice is given for choosing which
>> algorithm user want.
>>
>> I'm proposing to create something like:
>>
>> Gamma gammaFun = new Gamma(); gammaFun.value( x );
>> Gamma gammaFun = new LanczosGamma(); gammaFun.value( x );
>> Gamma gammaFun = new StirlingsGamma(); gammaFun.value( x );
>> Gamma gammaFun = new SpougesGamma(); gammaFun.value( x );
>>
>> Also as the class name suggestion {{LanczosApproximation}} it should
>> execute/implement full *Lanczos Algoritham* but we are just computing
>> coefficients in that class which is incorrect, so just refactoring is
>> needed which wont break any dependency of this class anywhere. (will
>> modify
>> code such way).
>>
>> let me know your thoughts?
>>
>>
> I've added a comment (about the multiple implementations) on the
> JIRA page.
>
> I agree that if the class currently named "LanczosApproximation" is
> not what the references define as "Lanczos' approximation", it should
> be renamed.
> My preference would be to "hide" it inside the "Gamma" class, if we
> can sort out how to modify the "GammaDistribution" class (in Commons
> Math) accordingly.
>
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message