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 NUMBERS-38, please review. [1] https://github.com/apache/commons-numbers/pull/5 Regards, Amey On Wed, Jun 7, 2017, 4:44 AM Gilles <gil...@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 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 > >
