Should I Use "sqrt(n)" or "pow(n,0.5f)"?

Should I Use "sqrt(n)" or "pow(n,0.5f)"?

Tobias Dammers

Member #2,604

August 2002

BlackShark said:

Give this Square root function a go,

Have you tried that on a 64bit platform? Or a PowerPC?

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Thomas Harte

Member #33

April 2000

Kris Asick said:

I'm still kinda surprised how many people responded to a question I thought was really simple and unimportant.

And not one of them mentioned powf or sqrtf, which I assume may well outperform pow an sqrt with no negative side effects if you're dealing with floats anyway. I think they're both C99, so possibly available on MSVC.

[My site] [Tetrominoes]

William Labbett

Member #4,486

March 2004

Just to add a pointless observation :

you've got other options.

int root_n(int n)
{
int root = n;

while(pow(root--, 2) != n)
;

return n;
}

EDIT : oh, if someone would just say "We know you can code in C to some extent.", I'd be able to stop trying to prove myself.

Arthur Kalliokoski

Second in Command

February 2005

Doesn't decrementing a variable within parameters to a function leave the original unchanged?

They all watch too much MSNBC... they get ideas.

William Labbett

Member #4,486

March 2004

Well spotted.

I had a look through my C book and since there's no example of doing this, I surmise you must be right.

Arthur Kalliokoski

Second in Command

February 2005

There's always the possibility of making a quick test program

#include <stdio.h>

int main(void)
{

    int i = 5;
    printf("\ni is originally %d",i);
    printf("\ni decremented = %d",--i);
    printf("\nand i is now %d",i);
    printf("\npress ENTER to exit");
    getchar();
    return 0;
}

and it seems to affect i permanently?!!?

They all watch too much MSNBC... they get ideas.

William Labbett

Member #4,486

March 2004

598599

and I did use your code! so it looks like the assumption I made was erroneous.

Arthur Kalliokoski

Second in Command

February 2005

Uh, what? My assumption was that it would print "and i is now 5", which it did not, so your assumption was correct.

They all watch too much MSNBC... they get ideas.

Neil Black

Member #7,867

October 2006

Mr. Labbett, I see that you can code in C to some extent. Good job! You capabilities are known amongst your peers, and you have become respected to some extent.

William Labbett

Member #4,486

March 2004

Arthur :

I meant this assumption I made :-

Will said:

I had a look through my C book and since there's no example of doing this, I surmise you must be right

..or was it a surmition ?

Neil :

thanks, I feel I can move on now.

Tobias Dammers

Member #2,604

August 2002

Arthur Kalliokoski said:

Doesn't decrementing a variable within parameters to a function leave the original unchanged?

No.
Both -- operators decrease the variable they act upon in-place, and return its value. The prefix -- operator returns the value after the decrement, the postfix -- operator returns the value before the decrement.
However, the code example:

int root_n(int n)
{
int root = n;

while(pow(root--, 2) != n)
;

return n;
}

...never changes the value of n, so it always returns the input unchanged, so it only "works" for n == 1 and n == 0. Also, for negative n, it will loop indefinitely, because the pow() call always returns a non-negative number, so the while condition is always true regardless of the value of root.

Neil Black said:

Mr. Labbett, I see that you can code in C to some extent.

It is valid C, I give you that.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

William Labbett

Member #4,486

March 2004

return root;

of course. ..and some error checking wouldn't hurt. Apologies for you have to point out my mistake Tobias.

BlackShark

Member #9,796

May 2008

Tobias Dammers said:

Have you tried that on a 64bit platform? Or a PowerPC?

no i have not, why?

-BlackShark

gillius

Member #119

April 2000

Thomas Harte said:

And not one of them mentioned powf or sqrtf, which I assume may well outperform pow an sqrt with no negative side effects if you're dealing with floats anyway.

My understanding is that, at least for x87 (or is it just x86 now) architecture, all of the floating point math is done internally on 80-bit numbers, making the 32-bit and their equivalent 64-bit floating point operations essentially equal in time.

I would imagine the same is true of 8,16,32-bit integer math on a 32bit CPU, and additionally 64 bit math on a 64 bit CPU (or more if using MMX/SSE/3dnow type instructions).

I don't have any hard experimental evidence of this, just years of hearing about the architecture makes me conclude this. Maybe someone knows otherwise.

Gillius
Gillius's Programming -- https://gillius.org/

Arthur Kalliokoski

Second in Command

February 2005

gillius said:

all of the floating point math is done internally on 80-bit numbers, making the 32-bit and their equivalent 64-bit floating point operations essentially equal in time

The precision can be set to how many bits to calculate, affecting some operations. Also, if the size of double vs. float can affect whether or not an array of floating point type numbers overflows the cache can make a difference.

They all watch too much MSNBC... they get ideas.

gillius

Member #119

April 2000

I was thinking about the memory bandwidth in the back of my mind, and whether or not the memory access was fast enough to make the cache irrelevant, since sqrt and pow are pretty expensive operations.

I know starting with the Pentium 4, the cache misses started to get to be a pretty big deal because of the CPU being so much faster than the RAM. I don't know if that gap is widening or narrowing these days.

Gillius
Gillius's Programming -- https://gillius.org/

Tobias Dammers

Member #2,604

August 2002

BlackShark said:

no i have not, why?

Because you use some nasty conversion between integers and floats there, one of the rare cases where the actual memory representation of floats and ints, which is platform dependent, may break your code.
On a 64 bit platform, long may be 64 bits instead of the expected 32, and dereferencing a long* that has been cast from a float* may produce an access violation (you're accessing 64 bits through a pointer that only has 32 bits allocated). You just can't assume that both long and float are 32 bits wide; although they are on virtually all common 32 bit platforms, they don't have to be.
On a PowerPC, endianness is different, so your bitwise logic may not work as expected (unless the byte ordering for floats is also reversed).

gillius said:

I don't know if that gap is widening or narrowing these days.

I don't know either, but I imagine two or more CPU cores competing for memory access doesn't make things easier for the RAM.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén