opPow, opDollar

[Pelle Månsson]

dsimcha 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 am all in favor of adding convenience functions sum and product to 
phobos. I use them both often enough.