On Thu, 2010-11-18 at 12:06 +0100, Lars Tandle Kyllingstad wrote:
> On Wed, 2010-11-17 at 22:09 +0100, Don Clugston wrote:

> > (2) Delete etc.gamma
> 
> I didn't even know this module existed.  I recently implemented the gamma function myself, based on the same source (Cephes).  If I'd known about this it would have saved me quite a bit of time, so I say yes, let's bring it out of hiding.

Actually, it seems etc.gamma doesn't get included in the DMD releases, it's just hanging around doing nothing in the Phobos repo...

-Lars

On Thu, 2010-11-18 at 12:06 +0100, Lars Tandle Kyllingstad wrote:
> On Wed, 2010-11-17 at 22:09 +0100, Don Clugston wrote:
> 
> > (2) Delete etc.gamma
> 
> I didn't even know this module existed.  I recently implemented the gamma function myself, based on the same source (Cephes).  If I'd known about this it would have saved me quite a bit of time, so I say yes, let's bring it out of hiding.

Well, how about that -- it seems I would have saved even more time by realising that there is a tgamma() function in std.math already... :p (It seems to be slightly less accurate than the Cephes one, though, as it doesn't pass the unittests I wrote for my implementation.)

-Lars

BTW, I want statistical functions in Phobos. For example, dstats.summary looks good. Is there the plan to introduce such functions?

--
SHOO

(2010/11/18 6:09), Don Clugston wrote:
> I have a pile of functions I wrote for Tango, most of which are part of C99. I'd like to move them into Phobos. In the process, I'd like to clean up a few things in std.math.
>
> The main idea is that a new module, std.mathspecial, will contain
> mathematical Special Functions. In the long term, there could be quite
> a large number of these, but I think it will still be OK to have all
> of them declared in a single module.
> The implementations of these functions will mostly reside in
> std.internal.math.XXX. In many cases, the implementations are quite
> large.
>
> std.math will be restricted to low-level operations and "high school" mathematics.
>
> (1) Add two necessary functions to std.math:
>
> // Rounds x to the nearest int or long using the currently selected
> rounding mode
> // (MUCH faster than cast(int)).
> int rndint(real x)
> long rndlong(real x)
>
> (2) Delete etc.gamma
>
> (3) Create a new module std.mathspecial.
>
> Move the following functions from std.math into std.mathspecial:
> erf()
> erfc()
> lgamma() ----->  name changes to logGamma(real x)
> tgamma() --->  name changes to gamma(real x).
> BTW The 't' in the C name exists for extremely silly historical reasons.
>
> std.math will retain alias for these functions, before they are eventually deprecated.
>
> (4) Add implementations of those functions into std.internal.math.gammafunction
> Also add:
> real sgnGamma(real x);    // the sign of gamma(x), always used with logGamma.
> real digamma(x);   //  The digamma function
> real beta(real x, real y);    // the beta function
>
> I'm not sure about the naming for the other functions. I will leave
> that for a later discussion.
> They include:
> * Distribution functions for the normal, F, chi-square, students-T, gamma, beta,
> poisson, binomial, and negative binomial distributions.
> * Cylindrical Bessel functions
> real cylBessel_j0(real x)  real cylBessel_y0(real x)
> real cylBessel_j1(real x)  real cylBessel_y1(real x)
> real cylBessel_jn(int n, real x )  real cylBessel_yn(int n, real x)

On 18 November 2010 12:40, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
> On Thu, 2010-11-18 at 12:06 +0100, Lars Tandle Kyllingstad wrote:
>> On Wed, 2010-11-17 at 22:09 +0100, Don Clugston wrote:
>>
>> > (2) Delete etc.gamma
>>
>> I didn't even know this module existed. ?I recently implemented the gamma function myself, based on the same source (Cephes). ?If I'd known about this it would have saved me quite a bit of time, so I say yes, let's bring it out of hiding.
>
> Well, how about that -- it seems I would have saved even more time by realising that there is a tgamma() function in std.math already... :p (It seems to be slightly less accurate than the Cephes one, though, as it doesn't pass the unittests I wrote for my implementation.)

Really? It started life as the Cephes one. I ported it to D, then Walter ported it back to C and put in the C standard library, where it is called from D (!) If you find a case where it fails, please let me know.

I have D ports of pretty much all of Cephes. The main value I added is unit tests to get high code coverage (well over 90%).

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101118/a8d569ba/attachment.html>

On Thu, 2010-11-18 at 14:29 +0100, Don Clugston wrote:
> On 18 November 2010 12:40, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
> > On Thu, 2010-11-18 at 12:06 +0100, Lars Tandle Kyllingstad wrote:
> >> On Wed, 2010-11-17 at 22:09 +0100, Don Clugston wrote:
> >>
> >> > (2) Delete etc.gamma
> >>
> >> I didn't even know this module existed.  I recently implemented the gamma function myself, based on the same source (Cephes).  If I'd known about this it would have saved me quite a bit of time, so I say yes, let's bring it out of hiding.
> >
> > Well, how about that -- it seems I would have saved even more time by realising that there is a tgamma() function in std.math already... :p (It seems to be slightly less accurate than the Cephes one, though, as it doesn't pass the unittests I wrote for my implementation.)
> 
> Really? It started life as the Cephes one. I ported it to D, then Walter ported it back to C and put in the C standard library, where it is called from D (!) If you find a case where it fails, please let me know.

These are the unittests that failed when I tried with std.math.tgamma(). As you see, they pass with the D version in etc.


import etc.gamma, std.math;

alias etc.gamma.tgamma etcGamma;
alias std.math.tgamma  stdGamma;

void main()
{
    // Smallish argument, tested to the accuracy claimed by
    // the Cephes documentation.
    enum gamma20 = 1.2164510040883200000e17L;
    assert (approxEqual(etcGamma(20.0L), gamma20, 3.6e-19L));
    assert (approxEqual(stdGamma(20.0L), gamma20, 3.6e-19L)); //fails

    // Very large argument, tested to an accuracy which is
    // lower than the one claimed by the Cephes documentation.
    enum gammaLarge = 9.3775451196074554961e4929L;
    assert (approxEqual(etcGamma(1754.9L), gammaLarge, 1e-15L));
    assert (approxEqual(stdGamma(1754.9L), gammaLarge, 1e-15L)); //fails
}


> I have D ports of pretty much all of Cephes. The main value I added is unit tests to get high code coverage (well over 90%).

Really?  I am very interested!  Do you have it in a public repo somewhere?

-Lars

Things are not going well...

However, these statistics functions are used depending on a case well.
In addition, I think that it is not overengineering about only
dstats.summary when I watch recent Phobos.
I think it seems to be worth being included in Phobos.

It seems to be necessary to look at the state for a while.

--
SHOO

(2010/11/18 22:49), David Simcha wrote:
> Others have suggested this in the past. There are/were a few major things holding it up:
>
> 1. While I feel that dstats.summary has about the right level of complexity/engineering for a third-party statistics lib, I'm a little worried that it's overengineered for a standard library module.
>
> 2. The brokenness of alias this. I designed the hierarchy of different summary-calculating output ranges to rely heavily on alias this. The relevant bugs may have been fixed recently, in 2.050. I'll have to check.
>
> 3. A bunch of stuff uses TempAlloc for its temporary scratch space. I'd like to keep it that way for efficiency, but it's hard to put TempAlloc into Phobos given that the issue of GC scanning *still* isn't solved.
>
> One solution to these problems is to just move the more basic stuff over to Phobos and publicly import it from dstats.summary.
>
> On 11/18/2010 8:00 AM, SHOO wrote:
>> BTW, I want statistical functions in Phobos. For example,
>> dstats.summary looks good. Is there the plan to introduce such functions?
>>
>> --
>> SHOO
>>