> (b) Include them in std.math, even if it means std.math will eventually become very large.

What actually would be really cool is having generic algorithms to compute the various special functions (probably just using something brute-force like the power series) and use those for complex and arbitrary-precision versions (see http://home.comcast.net/~benhinkle/gmp-d/). That would be really cool to have all the standard math functions (including min/max and friends) that just work for ints, reals, creals and arbitrary-precision floats. I should add arbitrary-precision complex to gmp-d and then that could work, too. Anyway... I'm just dreaming out loud here about what a *nice* std.math would look like. :-)

"Charles" <noone@nowhere.com> wrote in message news:de3034$fhe$1@digitaldaemon.com...
> Not sure why math2 even exists, why not throw them all in math ?

Because of Pavel's copyright on it. The stuff needs to be reimplemented to get around it, or math2 needs to be moved into etc.

Ben Hinkle wrote:
>>(b) Include them in std.math, even if it means std.math will eventually become very large.
> 
> 
> What actually would be really cool is having generic algorithms to compute the various special functions (probably just using something brute-force like the power series) and use those for complex and arbitrary-precision versions (see http://home.comcast.net/~benhinkle/gmp-d/). That would be really cool to have all the standard math functions (including min/max and friends) that just work for ints, reals, creals and arbitrary-precision floats. I should add arbitrary-precision complex to gmp-d and then that could work, too. Anyway... I'm just dreaming out loud here about what a *nice* std.math would look like. :-) 
> 
> 


I'm not entirely sure that the generic functions like min(), sum() belong in std.math. But, if there were generic algorithms for power series, I might change my mind.
My "gut feel" is that std.math is for functions that operate on and return real numbers, std.complex or std.cmath would operate on complex or imaginary numbers.
Template functions like "min" could be applied in non-mathematical contexts (eg, you might want to find the smallest FunkyWidget),
One possibility is to follow the STL from C++ and create a std.algorithm. Of course the STL made some very strange decisions,
accumulate() isn't with the other functions, for example.

----
With Walters comment about Pavel's copyright, I suggest that std.math2 be moved to etc for the time being. Or at least, don't bother documenting it.
Just throw abs() into std.math, it's important and trivial.

While we're on the subject, here's another quick function which exposes the x86 "fsincos" asm instruction. C99 considered including cis() but eventually rejected  it; but I think the argument is stronger for D since (a) D has mandated the use of IEEE floats (and therefore x86 is a very significant platform), and (b) complex reals are more strongly embedded in the language.

Might belong in std.cmath or std.complex, rather than std.math.
-------------------------------------------------

SOME DOC CHANGES FOR std.math:

The documentation for sin(x) in VC++2003 states:
"If x is greater than or equal to 2^63, or less than or equal to -2^63
a loss of significance in the result occurs."
That's a massive understatement. In fact, outside this range the results from the fsin, fcos instructions are nonsense. sin(1e20) returns 1e20.

So the docs for sin(x), cos(x), cis(x) should state:
"sin(x) is valid only for abs(x) < 0x1p+63 (approx 9e18). Outside this range, the results are undefined."

tan(x) seems to be unaffected by this.

Also, in the "constants" section, it might be helpful to add the line:
"These are the closest representable numbers to the corresponding mathematical constant. Because the precision is not infinite, results
may not be what you expect. For example, sin(2*PI) will not be <i>exactly<i> zero; instead, it will be about 1e-20 on most systems."

There should be one line descriptions of what each constant is, as well.
Trivial, but it would bring the docs closer to 1.0.

-Don.
------------------------------------------------------
//  cis(theta) = cos(theta) + sin(theta)i.
version (X86)
{
    // On x86, this is almost twice as fast as sin(x) + 1.0i*cos(x).
    creal cis(real x)
    {
     asm {
         fld x;
         fsincos;
         fxch st(1), st(0);
      }
    }
} else {

    creal cis(real x)
    {
      return cos(x) + sin(x)*1i;
    }

}

unittest {
    assert(cis(0)==1+0i);
    assert(cis(1.3e5)==cos(1.3e5)+sin(1.3e5)*1i);
    creal c = cis(real.nan);
    assert(isnan(c.re) && isnan(c.im));
    c = cis(real.infinity);
    assert(isnan(c.re) && isnan(c.im));
}

"Don Clugston" <dac@nospam.com.au> wrote in message news:deb35e$1rre$1@digitaldaemon.com...
> Ben Hinkle wrote:
>>>(b) Include them in std.math, even if it means std.math will eventually become very large.
>>
>>
>> What actually would be really cool is having generic algorithms to compute the various special functions (probably just using something brute-force like the power series) and use those for complex and arbitrary-precision versions (see http://home.comcast.net/~benhinkle/gmp-d/). That would be really cool to have all the standard math functions (including min/max and friends) that just work for ints, reals, creals and arbitrary-precision floats. I should add arbitrary-precision complex to gmp-d and then that could work, too. Anyway... I'm just dreaming out loud here about what a *nice* std.math would look like. :-)
>
> I'm not entirely sure that the generic functions like min(), sum() belong in std.math. But, if there were generic algorithms for power series, I might change my mind.

Where would you put min/sum/etc?

> My "gut feel" is that std.math is for functions that operate on and return real numbers, std.complex or std.cmath would operate on complex or imaginary numbers.

The problem with using multiple modules is that D's overloading rules are
very strict and so user code can't import both std.math and std.complex and
freely mix calls to functions overloaded between modules. So for example if
sin was defined in std.math and std.complex then writing sin(x) would be
illegal - it would have to be explicitly written as std.math.sin(x) or
std.complex.sin(x) or users would have to alias sin in the current module.
So with D if there's a chance two modules will be used at the same time they
should not overload each other.
Personally I think using std.math for "all things mathematical" is natural.
Even mathematical operations like min/max that can be applied to anything
that overloads < or > or whatever. It's still most commonly used as a
mathematical operation. Maybe we need std.math and std.mathwannabes.

> Template functions like "min" could be applied in non-mathematical
> contexts (eg, you might want to find the smallest FunkyWidget),
> One possibility is to follow the STL from C++ and create a std.algorithm.
> Of course the STL made some very strange decisions,
> accumulate() isn't with the other functions, for example.

Sounds reasonable - and std.math can import whatever has the min/max/etc so that user code doesn't have to import lots of stuff just to do basic math operations.

Ben Hinkle wrote:

> "Don Clugston" <dac@nospam.com.au> wrote in message news:deb35e$1rre$1@digitaldaemon.com...
> 
>>Ben Hinkle wrote:
>>
>>>>(b) Include them in std.math, even if it means std.math will eventually become very large.
>>>
>>>
>>>What actually would be really cool is having generic algorithms to compute the various special functions (probably just using something brute-force like the power series) and use those for complex and arbitrary-precision versions (see http://home.comcast.net/~benhinkle/gmp-d/). That would be really cool to have all the standard math functions (including min/max and friends) that just work for ints, reals, creals and arbitrary-precision floats. I should add arbitrary-precision complex to gmp-d and then that could work, too. Anyway... I'm just dreaming out loud here about what a *nice* std.math would look like. :-)
>>
>>I'm not entirely sure that the generic functions like min(), sum() belong in std.math. But, if there were generic algorithms for power series, I might change my mind.
> 
> 
> Where would you put min/sum/etc?

These functions switch on the traits of a comparable type - there are also traits for arrays, strings, numerics, integrals, fractionals and complex (that's where std.math comes in), and others to work with.  A library organisation could have it as:

   module std.tcomparable;

   template TComparable(T)
   {
       T min(T[] list...)
       {
           assert (list.length);

           T result = list[0];

           foreach (T item; list[1..$])
               if (item < result)
                   result = item;

           return result;
       }
   }

But I don't think it's worth doing this to Phobos, because it's such a large restructuring.

By the way, that's the only implementation of min you need - you can pass an array to a variadics-array-taking function.

>>My "gut feel" is that std.math is for functions that operate on and return real numbers, std.complex or std.cmath would operate on complex or imaginary numbers.
> 
> 
> The problem with using multiple modules is that D's overloading rules are very strict and so user code can't import both std.math and std.complex and freely mix calls to functions overloaded between modules. So for example if sin was defined in std.math and std.complex then writing sin(x) would be illegal - it would have to be explicitly written as std.math.sin(x) or std.complex.sin(x) or users would have to alias sin in the current module. So with D if there's a chance two modules will be used at the same time they should not overload each other.

Yeah, it's a real pain in the ass how D makes writing functions a mandatory part of its engineering but supports them so horribly.  The same problem applies to mixins.

The claim is that this way prevents bugs, but what it really does is put pitfalls into developing and maintaining code.  D's very simple function overloading will still catch any ambiguous conflict.

> Personally I think using std.math for "all things mathematical" is natural. Even mathematical operations like min/max that can be applied to anything that overloads < or > or whatever. It's still most commonly used as a mathematical operation. Maybe we need std.math and std.mathwannabes.
> 
> 
>>Template functions like "min" could be applied in non-mathematical contexts (eg, you might want to find the smallest FunkyWidget),
>>One possibility is to follow the STL from C++ and create a std.algorithm. Of course the STL made some very strange decisions,
>>accumulate() isn't with the other functions, for example.
> 
> 
> Sounds reasonable - and std.math can import whatever has the min/max/etc so that user code doesn't have to import lots of stuff just to do basic math operations. 

>> Where would you put min/sum/etc?
>
> These functions switch on the traits of a comparable type - there are also traits for arrays, strings, numerics, integrals, fractionals and complex (that's where std.math comes in), and others to work with.  A library organisation could have it as:
>
>    module std.tcomparable;
>
>    template TComparable(T)
>    {
>        T min(T[] list...)
>        {
>            assert (list.length);
>
>            T result = list[0];
>
>            foreach (T item; list[1..$])
>                if (item < result)
>                    result = item;
>
>            return result;
>        }
>    }
>
> But I don't think it's worth doing this to Phobos, because it's such a large restructuring.

I don't follow - what large restructuring? Aren't we just talking about std.math2?

> By the way, that's the only implementation of min you need - you can pass an array to a variadics-array-taking function.

Neat. I didn't know that.

Ben Hinkle wrote:
>>>Where would you put min/sum/etc?
>>
>>These functions switch on the traits of a comparable type - there are also traits for arrays, strings, numerics, integrals, fractionals and complex (that's where std.math comes in), and others to work with.  A library organisation could have it as:
>>
>>   module std.tcomparable;
>>
>>   template TComparable(T)
>>   {
>>       T min(T[] list...)
>>       {
>>           assert (list.length);
>>
>>           T result = list[0];
>>
>>           foreach (T item; list[1..$])
>>               if (item < result)
>>                   result = item;
>>
>>           return result;
>>       }
>>   }
>>
>>But I don't think it's worth doing this to Phobos, because it's such a large restructuring.
> 
> 
> I don't follow - what large restructuring? Aren't we just talking about std.math2?

I mean that min/max is part of a much broader set of template mixins that have specialised, stunted forms all throughout Phobos; std.string is a specialisation of a string mixin, std.math is a fractional mixin (specifically a specialisation on the floating-point types to use the intrinsics - the general form would use approximating algorithms), array properties are a miniscule subset of an array mixin.  It would be very valuable to have those templates in a standard library; they'd have richer functionality and they would work with user types.  However, I don't think it's worth trying to reform Phobos to such an extent.

I'm not talking about a template library like MinTL - instead one that purely functions with the builtin types.