On Sat, 07 Nov 2009 11:26:36 -0500, dsimcha <dsim...@yahoo.com> wrote:
== Quote from Robert Jacques (sandf...@jhu.edu)'s article
On Sat, 07 Nov 2009 10:48:11 -0500, KennyTM~ <kenn...@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.
