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 Wed, Nov 17, 2010 at 4:09 PM, Don Clugston <dclugston at googlemail.com>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.
>

Vote++.  I think Phobos could use more math stuff.


>
> (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)).
>

Why isn't this the default, i.e. why doesn't cast(int) do this?

> int rndint(real x)
> long rndlong(real x)
>
> (2) Delete etc.gamma
>

Good, didn't know it was there.

>
> (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.
>

Vote++.  I'm sick of maintaining the D2 ports of this stuff myself for dstats.  It also makes the licensing status of dstats slightly screwy since I initially got them from Tango.  (I was smart enough, though, to clearly mark the tainted parts for future removal.)


> * 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)
>

I've got no clue what these even are, but given that they're just math functions that are orthogonal to the rest of the standard library, I don't see any harm in adding them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101117/873a7f65/attachment.html>

On Wed, 17 Nov 2010 22:09:10 +0100
Don Clugston <dclugston at googlemail.com> wrote:

> (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)

Please use full words when abbr is not absolutely obvious and/or the gain in typing is small (esp for rarely used functions). The functions above may return random int and real, respectively. (also sgngamma --> signgamma)


Denis
-- -- -- -- -- -- --
vit esse estrany ?

spir.wikidot.com

Plan sounds good to me. Thanks for your great work, Don. A couple of comments below.

On 11/17/10 1:09 PM, Don Clugston wrote:
> (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)

To an uninitiated reader this may look like "random int" and "random long". Could we define this instead?

N roundTo(N)(real x) if (isIntegral!N);

Then use will be self-explanatory:

auto m = roundTo!int((a + b) / 2);

Feel free to constrain further to only e.g. int and long, or (at best) generalize to unsigned types and to types narrower than int.

> (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.

deprecated("Please use the homonym functions in std.mathspecial.")

:o)


Andrei

On Wednesday 17 November 2010 13:09:10 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.

Is there a particular reason not to just put them all in std.math? It at least seems like it would be simpler to do that - particularly from a usage standpoint. I take it that there's some reason why that's undesirable?

- Jonathan M Davis

David Simcha <dsimcha at gmail.com> wrote:

>> (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)).
>>
>
> Why isn't this the default, i.e. why doesn't cast(int) do this?

Second this. If it's not so complex Walter can't possibly understand it, or it may cause bees to spurt from your floppy drive, it sounds like what cast(int) should do.

-- 
Simen

On 11/17/10 1:56 PM, Simen Kjaeraas wrote:
> David Simcha <dsimcha at gmail.com> wrote:
>
>>> (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)).
>>>
>>
>> Why isn't this the default, i.e. why doesn't cast(int) do this?
>
> Second this. If it's not so complex Walter can't possibly understand it, or it may cause bees to spurt from your floppy drive, it sounds like what cast(int) should do.

cast(int) always truncates, whereas Don's function uses the current rounding mode.

Andrei

Le 2010-11-17 ? 16:09, Don Clugston a ?crit :

> 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.

"Special"... what's special about these functions? I'm not sure why they can't be in std.math, but if we have this module I don't feel "special" is an appropriate term for it. Supplement, Advanced, Extra might be better terms.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

Le 2010-11-17 ? 16:36, Andrei Alexandrescu a ?crit :

> On 11/17/10 1:09 PM, Don Clugston wrote:
>> 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.
> 
> deprecated("Please use the homonym functions in std.mathspecial.")

But won't that just become a convenient excuse to forget putting the deprecation notice in the documentation? It sounds redundant:

/**
 * Blah blah blah...
 * Deprecated: use the homonym functions in std.mathspecial.
 */
deprecated("use the homonym functions in std.mathspecial")
double lgamma(double);

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

>> (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)).
>
> Why isn't this the default, i.e. why doesn't cast(int) do this?

Because C stuffed up in a major way, and we have to live with it. Intel has tried THREE TIMES to fix C's mistake, by making hardware changes and adding new instructions to their CPUs.

> Please use full words when abbr is not absolutely obvious and/or the gain in typing is small (esp for rarely used functions).
>  (also sgngamma --> signgamma)

I didn't invent the name. sgn is the signum function. See, for example, http://en.wikipedia.org/wiki/Sign_function

>To an uninitiated reader this may look like "random int" and "random long".

Ugh, you're right.

>Could we define this instead?
> N roundTo(N)(real x) if (isIntegral!N);

That sounds a bit too formal. I would expect that to perform some
exact form of rounding (certainly not round-to-nearest, which seems
irrational to our uninitiated reader). I would also expect it to do
something sensible when the value is > int.max.
This function should really be an intrinsic, and it only makes sense
for int and long.

fastRoundInt(real x)
fastRoundLong(real x)
?
A bit clumsy, but should be unambiguous.

>Is there a particular reason not to just put them all in std.math? It at least seems like it would be simpler to do that - particularly from a usage
> standpoint. I take it that there's some reason why that's undesirable?

Three reasons.
1. std.math includes some very simple, well known stuff like sqrt()
and abs(). It's extremely daunting for a casual user to be hit with
advanced mathematics.
2. The "Special Functions" are a well-defined group of functions. They
form a very natural common namespace.
Even for people (like me) who use them, they're typically only
imported into one or two modules in the whole project. By contrast,
std.math is imported into nearly module I have.
3. If you put them into std.math, you then have to ask, why isn't
everything else in std.math too? Linear algebra? Where do you stop?
Creating mathspecial sends a clear message: std.math is just for
elementary functions and low-level functions.

>"Special"... what's special about these functions? I'm not sure why they can't be in std.math, but if we have this module I don't feel >"special" is an appropriate term for it. Supplement, Advanced, Extra might be better terms.

They are called "Special Functions" in mathematics.
eg, http://eqworld.ipmnet.ru/en/auxiliary/aux-specfunc.htm