I did. And you still haven't provided an answer to what we're asking, namely: "When you can do something right for no more cost or effort than doing it wrong - why the hell should you choose to do it the wrong way?"

22/7 = 3.1428571428571428571428571428571
pi = 3.1415926535897932384626433832795
22/7 - pi = 0.00126448926734961868021375957764
pi - 3.14 = 0.0015926535897932384626433832795029

22/7 is a better aproximation to pi than 3.14. I frequently saw 3.14 being used as a aproximation to pi in several games without any noticeable glitch caused by that. So 22/7 should be ok for many practical purposes too.

However, something that should be noted is that 22/7 > pi and 3.14 < pi, this could make a difference in some cases.

[offtopic Edit:]
The ancient egiptyans used 19/6 for pi, which is worst than 22/7.

It can be very noticable. The example I gave for firing missiles across the screen was from experience: a missile fired from the left of the screen towards a stationary target on the right of the screen under an angle would miss because I was trying to be clever and calculate with lower accuracy.

But yes, the point was that if youcan do it right, why wouldn't you?

Hey, if everyone else is jumping into this...

I would think that defining your own PI variable would be more efficient than calling "22/7" each time the function is called. Just less math that the computer has to compute in the routine.

That way, you have a 3- 5- or n- precision number to your liking that's been calculated ONCE and you don't need to run the math through every time.

I would think that M_PI, PI, AL_PI, or simply float MY_PI = 3.1415 would increase the speed of the function.

#define MY_PI 3.14159

double grad2rad( int grad_angle ){
  return (double)(MY_PI * ((double) grad_angle))/180.0;
}

Just my 2 cents...

You're still dodging the core issue. Typing M_PI instead of 22/7 would give you superior accuracy at no cost whatsoever. How can one even possibly defend doing this wrong?

There's a pretty good chance 22/7 will be calculated at compile time, yes. Constant expressions are a pretty trivial optimization.

Do some profiling, or write a simple benchmark program.

Is float really faster than double? On modern processors, I strongly doubt that...

A float is a float is a float, whatever number of digit you try to put into it (after the , of course).

Division needs several cycles, so a measure would be needed.

From my memory (can't find the article I've read about this some time ago ) I recall that modern processors need 1 clock cycle for one multiplication. Regardless of the numbers being float or double. Have to find the reference article though...

I made a little (ugly [I'm still a beginner at it]) Haskell program:

fractions = [(x,y) | x <-[1.0, 2.0..250.0] , y <-[1.0, 2.0..250.0] ]
difference f = map (\(x,y) -> abs (pi - x/y)) f
fracwithdiff = zip fractions (difference fractions)

approx [] ((a,b),c) = ((a,b),c)
approx (((x,y),z):xs) ((a,b),c) = if z < c then approx xs ((x,y),z) else approx xs ((a,b),c)

When I run it:

Main> approx fracwithdiff ((1,1),1)
((245.0,78.0),0.000567012564152147)
Main>

So instead of writing 22.0/7.0 you could write 245.0/78.0 and get even better precision. Hehe, but that was of course just for fun. Using a well defined constant is the nicest approach.

You're wrong then. Especially if you're doing a lot of floating point calculations you can really notice the difference. I suspect it is mainly a bandwith issue, however.

Yes, except if the number of bytes in which it is stored is different (obviously).

Re-read gnolam's post (or my earlier post). Especially the bit that says When you can do something right for no more cost or effort than doing it wrong.

If you're only going to need three significant digits, then you may want to have pi to only three significant digits as well. That's not doing it wrong, that's doing it with limited precision. What's wrong is using a value of pi that is accurate to three digits while the rest of your numbers are accurate to sixteen (say) digits. Which is what I've said two times already.
That said, cumulative errors from intermediate rounding reallydo matter, and you should not round until the last step if you can possibly avoid it. I've once had a discussion about that when I was in highschool with my chemistry teacher, who maintained that it's ok. Which was why his answers were always a bit off in the last few digits "due to rounding errors".

Did you benchmark that or did you pull that from thin air? float<--->int conversions are slow in themselves.

I thought the registers in a 64-bit processor was of length 64-bit. And that's how you classify a 64-bit processor. Are you saying that todays 64-bit processors in fact have registers holding 96-bit?

My collaborator doing hydrodynamical simulations of colliding stars says otherwise from experience, and I sooner believe him. As I said, I suspect it's a bandwidth issue.
Personally I always use doubles for the extra precision.

I'm reading through the "Intel 64 and IA-32 Architectures Software Developer's Manual", downloaded from www.intel.com.

The table on page 53 gives a lot of numbers: For all Pentium processors, the external data bus has 64 bits. The general purpose registers all have 32 bits. The floating point registers have 80 bits. Then there are MMX registers, which all have 64 bits, and XMM registers, used for SSE2 and later, which all have 128 bits.

Internal data paths are 2-4 times wider than the external data bus.

This paper does only describe HOW the assembler statements work, not how many cycles they use. Next paper...

"IA-32 Intel Architecture Optimization Reference Manual" gives a lot of hints how to improve speed when dealing with anything. However, it seems that all this stuff is pretty complicated, and again, no numbers of clock cycles are given.

One thing I now have learned from this is: Most probably, it's entirely unimportant how many cycles the multiplication (or any operation) exactly has. There are other limiting factors, which mostly concern the ability of the processor to do things in parallel (blocking events), and when to get or store data. Cache is important here, branch prediction, and more...

So I would only go for correctness, then do profiling if things are too slow.