Hi Amey.
On Wed, 7 Jun 2017 01:15:01 +0530, Amey Jadiye wrote:
> 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));
Just from the look of it, it is difficult to figure out whether
alternative algorithms are useful when numbers are represented
as 64bits "double".
If you are willing to go that route, you should provide code that
shows the advantages (speed and/or precision).
Now, if we want to support an arbirary precision number type[1],
then the alternate algorithms that can provide accuracy below
~1e16 would certainly be worth considering.[2]
> I'd like other people from group chime in discussion.
Regards,
Gilles
[1] See the "Dfp" class in CM's "o.a.c.math4.dfp" package.
[2] But IMO this should be postponed to after 1.0 since there
is perhaps a need of a general discussion about designing
highprecision algorithms (and whether there are volunteers
to develop and support them in the long term).
I may be wrong, but somehow I have the intuition that people
requiring those functionalities might not be using Java...
>
> 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/NUMBERS38
>>>
>>> As Gamma is nothing but advanced factorial function gamma(n)=(n1)!
>>> 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^(x1) 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, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
