opPow, opDollar

[Robert Jacques]

On Sat, 07 Nov 2009 11:26:36 -0500, dsimcha <dsimcha at yahoo.com> wrote:

> == Quote from Robert Jacques (sandford at jhu.edu)'s article
>> On Sat, 07 Nov 2009 10:48:11 -0500, KennyTM~ <kennytm at gmail.com> wrote:
>> > On Nov 7, 09 18:43, Don wrote:
>> >> Walter Bright wrote:
>> >>> Don wrote:
>> >>>> A little while ago I said I'd create a patch for ^^ as an
>> >>>> exponentiation. A couple of people had requested that I make a post
>> >>>> to the ng so they'd know when it happens. Here it is.
>> >>>>
>> >>>> This is opPow(), x ^^ y
>> >>>>
>> >>>> http://d.puremagic.com/issues/show_bug.cgi?id=3481
>> >>>
>> >>> I don't understand the rationale for an exponentiation operator. It
>> >>> isn't optimization, because pow() could become an intrinsic that the
>> >>> compiler knows about. pow() is well known, ^^ isn't. (Fortran uses  
>> **)
>> >>
>> >> It's primarily about syntax sugar: pow() is so ugly. In practice, the
>> >> most important case is squaring, which is an extremely common  
>> operation.
>> >> pow(xxx,2) is horribly ugly for something so fundamental. It's so  
>> ugly
>> >> that noone uses it: you always change it to xxx * xxx. But then, xxx
>> >> gets evaluated twice.
>> >>
>> >
>> > Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
>> > primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
>> > practice, the most important case is the sum from 1 to n, which is an
>> > extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly  
>> ugly
>> > for something so fundamental. It's so ugly that noone uses it: you
>> > always change it to n*(n+1)/2. But then, n gets evaluated twice.
>> >
>> >> Yes, ^^ hasn't been used for exponentiation before. Fortran used **
>> >> because it had such a limited character set, but it's not really a
>> >> natural choice; the more mathematically-oriented languages use ^.
>> >> Obviously C-family languages don't have that possibility.
>> >>
>> >
>> Well, since D supports unicode, you can always define: alias
>> reduce!("a+b") ∑;
>
> On a more serious note, I'm starting to think that Phobos needs a  
> specific
> convenience function for sum, not because reduce!"a + b" is ugly (it  
> isn't) or too
> much typing (it isn't) but because reduce!"a + b" doesn't work on  
> zero-length
> ranges.  Obviously, the sum of a zero-length range is zero, but reduce  
> is too
> general to know this.  This bit me a few times in some code I was  
> debugging last
> week.  Rather than inserting extra checks or passing an explicit start  
> value in
> (which requires you to remember the element type of your range; is it an  
> int or a
> float?), I simply handwrote a sum function and replaced all my reduce!"a  
> + b" with
> sum.

I'd recommend rolling that into a basic statistics struct containing  
common single pass metrics: i.e. sum, mean, variance, min, max, etc.

P.S. Don't forget to vote for the patches in bugzilla.