Hi Gilles,
Thanks for inputs, I will generate some stats with jmh let's see if we are
getting benefits with my proposal.
Mean time I have submitted test cases[1] for NUMBERS38, please review.
[1] https://github.com/apache/commonsnumbers/pull/5
Regards,
Amey
On Wed, Jun 7, 2017, 4:44 AM Gilles <gilles@harfang.homelinux.org> wrote:
> 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
>
>
