Re: why use pow(x, 2)?
Re: why use pow(x, 2)?
- Subject: Re: why use pow(x, 2)?
- From: Mark Gallegly <email@hidden>
- Date: Mon, 02 Nov 2009 14:22:43 -0800
- Thread-topic: why use pow(x, 2)?
Hasn't this gone off topic? Shouldn't this be discussed on the pow(x,x) Vs.
x * x forum?
On 11/2/09 2:10 PM, "Luke the Hiesterman" <email@hidden> wrote:
> I can't speak for others, but I never meant to actually argue that pow
> (x, 2) is clearer than x * x. My argument was that each author should
> use whichever version he or she thinks is clearer. There are rarely
> absolutes about that sort of thing, as clarity is subjective by its
> very nature. I urge programmers to use the clearer choice, whatever
> that might be to them.
>
> Luke
>
> On Nov 2, 2009, at 2:01 PM, Chris Williams wrote:
>
>> How completely rude of you, Greg, to confuse a good argument with
>> facts :)
>>
>> But it still does leave the style question: is pow(x,2) clearer than
>> x*x?
>>
>> In the case from the OP, I think that the pow is clearer, because it
>> is
>> implementing an algorithm that calls specifically for x-squared.
>> And in the
>> case where x is not a simple variable, but rather an expression,
>> it's even
>> more clear (and less prone to typing errors).
>>
>> My $0.02...
>>
>>> From: Greg Parker <email@hidden>
>>> Subject: Re: why use pow(x, 2)?
>>>
>>> This is easy to test empirically. In this simple case, the compiler
>>> does optimize pow(x, 2) directly to a single-instruction x*x.
>>>
>>> % cat test.c
>>> #include <math.h>
>>> int main(int argc, char **argv) {
>>> return pow(argc, 2);
>>> }
>>> % cc -O3 test.c -o - -S
>>> [...]
>>> _main:
>>> LFB17:
>>> pushq %rbp // build stack frame
>>> LCFI0:
>>> movq %rsp, %rbp // build stack frame
>>> LCFI1:
>>> cvtsi2sd íi, %xmm0 // convert int argc to float
>>> mulsd %xmm0, %xmm0 // pow(argc, 2)
>>> cvttsd2si %xmm0, êx // convert float->int for return
>>> leave
>>> ret
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden