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 64-bits "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
~1e-16 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
high-precision 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 <gil...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
