std.array suggestion

[Don Clugston]

Oskar Linde wrote:
> Don Clugston wrote:
>> Oskar Linde wrote:
>> I'll just comment on one function:
>>
>>  > T sum(T[] arr)
>>  >
>>  > Returns the sum of the element in arr as defined by the + operator.
>>
>> This one has an interesting twist. I'm not sure that the sum should 
>> necessarily be of type T. I've been playing around with the concept of 
>> what I've called the Archetype of a type, which is the largest type 
>> with the same semantics as T (possibly with the same calculation 
>> speed). (ie,
>> Archetype!(byte)= Archetype!(short)
>> Archetype!(int) = long
>> Archetype!(float) = Archetype!(double) = real,
>> Archetype!(cfloat)= creal, etc). Obviously it's a trivial template.
> 
> Interesting...
> 
>> I think that at least,  sum(double[] ) should internally use a real 
>> while accumulating the sum, so that it can satisfy this test (at least 
>> on x86 platforms):
>>
>> unittest {
>>    const double a = [ double.max, double.max, -double.max];
>>    assert(sum(a) == double.max);
>> }
>>
>> After all, this is one of the reasons why reals exist. I'm still not 
>> sure if sum(double []) should return a double or a real, although I'm 
>> inclined to think that *any* function that returns a single floating 
>> point value should return a real (on x87, the 80-bit result is just 
>> left on the FPU stack anyway). But, I'm less confident about how a sum 
>> of ints should behave.
> 
> Int overflows is well defined, making the sum of ints behave correctly 
> in the case above. Int is also the promotion type for integral 
> operations and would be the natural return type for sum(int[]). A sum of 
> shorts should probably return an int though, following integer promotion 
> rules. Should Archetype for integers follow the integer promotion rules 
> or all be long?

I'm really not sure. But you make a good point -- if it mimics the 
promotion rules, it's easy to justify the choice.
There's an implementation of Archetype!() with a sum!() that behaves in 
this way at http://svn.dsource.org/projects/mathextra/trunk/mathtempl.d

I also have a sumList(a[]...) implementation there, but it's just an 
experiment. Doesn't work too well with the current IFTI limitations.

If IFTI worked for ... arguments, we could just write

template min(T)
{
    T min(T[]...) {
    }
}

and then it would work for both:
int z = 4;
int [] a = [3, 5, 67];

int x = min(5, 6, z, 2, 9);
int y = min(a);

but unfortunately ... arguments don't let you do the implicit property 
trick. So I don't know if it's a good idea or not.

>> However, all the other functions seem to be free of mathematical 
>> subtleties. sum() is the only one which involves arithmetic operators, 
>> and therefore it might not belong with the rest.
> 
> You make a strong argument and I agree. sum() is used as join() in other 
> languages that lack the distinction between addition and concatenation. 
> D doesn't need a non-arithmetic sum function.

The ~ operator was a stroke of genius. It has many wonderful consequences.