Hello, I got th following problem: a function is returning a value from type 'double', but the caller receives the wrong value. In the function's body all is correct, but the return value does not match. The prototype is as follows:
double grad2rad( int grad_angle );
and the body is:

double grad2rad( int grad_angle ){
  double new_angle;
  new_angle = (grad_angle/180.0)*PI;
  return new_angle;
}

PI is a constant: (22.0/7.0). Will be thankful for any help.

I don't see anything wrong. What you expect and what you get? Remember there may be rounding errors.

What's wrong with M_PI? Your code should look like this:

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

M_PI lives in <math.h> by the way...

Try this:

double grad2rad( int grad_angle ){
  double new_angle;
  new_angle = (PI * grad_angle)/180.0;
  return new_angle;
}

And if still doesn't works, then try this:

double grad2rad( int grad_angle ){
  double new_angle;
  new_angle = (PI * ((double) grad_angle))/180.0;
  return new_angle;
}

Edit: Or simpliest, but equivalent to that:

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

Thank you people, but the problem is not in the calculation, but in the data transfer (that's the reason I assign the value to a variable instead of just returning it). Before I return the variable, it has the right value, but afterwards not any more...

By the way, the result should be 1.570796 and the caller actually receives 1227133513.000000...

Are you using malloc or arrays somewhere? That sounds like memory corruption.

Show the "caller"'s code then.

Actually no. The problem was elsewhere...
The declaration of the function is in external header file and I forgot to include the corresponding header. The compiler didn't complain at all and I suspect it thought the return value is by default int or something like that, so it interpreted the data wrong. Strange stuff... Hopefully my failure helps someone else, who is experiencing the same problem.

you are right,in your situation the compiler will recognize the return value of
this function as int by default.

Normally lives in math.h, one should say. IIRC, M_PI is neither C89 nor C99. It might be POSIX, but I don't think MSVC supports it.

But either way, using 22/7 instead of a sensible value for pi is just silly.

It does (math.h, MSVC 7.1).

That is a horrible approximation.

It does if you enable warnings (which is always a good idea).

Well, at least it's better than 3.

I usually just use 3.142, no need to get more precise.

You people make mathematicians and your math teachers cry. Like this:

It depends on what you are doing, in computer games it's a waste to use many significant figures (unless, maybe, in some kind of advanced physics simulation), usually one or two are more than enough...

It's exactly that what Corelian was referring to...

And before you talk about performance, do some profiling to find out, where your program does spend its time. You will be surprised!

How? It is just as fast to use more correct digits as it is to use the same number of incorrect ones. What are you wasting?

Show me the advantage of using 10 instead of 3 significant figures in the average game... anyway using, for example, floats (less precision) instead of doubles is surely faster, likewise if i knew i was using 2 digits of precision i could simply treat everything as an int and just divide by 100 at the end, this would be much harder if i had to use M_PI (god knows how many digits of precision it uses).
I agree that this isn't a huge impact on performance but it just seems an overkill to use 20 digits of precision when at the end you're working with pixels (integers...)

I use AL_PI. Haven't a clue the difference as I never looked at M_PI and I know it'll work for every allegro program

Try shooting a missile or particle under a specific angle across the screen and see if it moves to where it's supposed to go. You'll be surprised at how far off course it will go. If you can do it right for the same cost as doing it wrong, why not do it right?

That wasn't what I asked you though. I asked you how it's wasteful to use the normal approximation of pi instead of, say, 22/7.

Even in simple games with simple physics basically what you're doing is you're numerically solving differential equations. For this task there are several methods but because for a simple game fourth order Runge-Kutta would be overkill, most people just use the Newton method (or whatever it's actually called). That's when you do x_pos = x_pos + velocity_x and things like that. The advantage of this method is that it is extremely easy to implement. The disadvantage though is that all random errors in data or whatever add up over time (with Runge-Kutta and other methods they effectively get canceled out in successive steps), which results in what Evert said. You fire a missile in a certain direction, but after many steps of physics simulation with the Newton method, the missile is several pixels off because of round off error that kept piling on and on at each step...

Did you read the rest of the post?

Agreed, but does it really matter much while playing?

<sarcasm on>
Seems there's no reason to do it right if you can also do it wrong.
<sarcasm off>

With some types of games it does. Suppose you have a racing simulation where you simulate the suspension and all other things. Now if after a few seconds the suspension starts to wobble more and more and finally goes completely out of control because you're physics simulation is unstable, then I'd say it matters.

Of course I did.

Did you get my point?

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?"

I'll restate what I was trying to point out in a more direct way: to no number of significant digits is it better to use 22/7 instead of the value of pi to said number of digits. The best case is 1 significant digit, for which case the difference is zero (since both are 3 in that case). The best case is for three digits, where pi is 3.14 and 22/7 is 3.15. It gets worse from there.

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.

The small inacuraces would hardly be noticable but I believe it is just better practice, from a programming perspective, to use M_PI or AL_PI (or just memorize 3.141592653589793238462643383279502..... Then you could create a multi-player game where the winner is the one who has more of PI memorized )

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?

If accuracy doesn't count, you might gain a bit of speed by using floats rather than doubles.

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...

It isn't wrong to use floats instead of doubles, it's wrong to use a poor approximation to pi if you can use pi proper (to a given number of digits).
As I said above,

EDIT

22/7 is a compile time constant, so it's evaluated at compile time (as opposed to runtime) by any decent compiler.
Anyway, if you're optimising that, you're probably optimising the wrong thing.

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?

That is wrong. AFAIK, the compiler calculates as many constant values as it can during compile-time (I think I've read that in an old K&R book, so it must be even better now) so it really doesn't matter. BTW, using that, you can still leave some constant expressions in your program to make it more readable, knowing that the compiler will take care of it.

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

I have seen where using a global variable is faster than a constant, as always, if it's not in a bottleneck, don't worry about it, else time it and see. It'd help if it was near to another recently used global if any.

const float mathpi = M_PI;

Last time I looked at the asm output for a defined double it had to allocate and write two separate 32 bit values to the stack.

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...

Except I never said to use 22/7 instead

Because there are "wrong" ways that do the job at a lower cost?
For example (as i wrote before), imagine i have a complicated function
(float f(float x);), if i knew only 3 digits of precisions are needed, i could simply multiply the entering value by 1000 and storing it in an int do all calculation using integers (faster), divide by an integer 3142, continue my calculations and only at the end divide by 1000.0 - if the function is complex enough you gain much more by using ints than what you loose for the 2 extra operations...
but really it's not really something important as either way it doesn't really matter.

I'd say a simulation is extensively based in physics, so it does make sense to use a good, even if complicated, model. That said i don't see how it hurts to use a rounded value if you are just using it for some particicle effects...

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.

It's not, floating point math isn't slow these days. With all those divisions (which may take dozens, if not hundreds of cycles) anyways. And floats aren't more processor efficient, they're only more memory efficient. Both floats and doubles are expanded to 96 bits before any calculations.

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 definitely have to find that article again. Also I'm used to consider 64 bit processors (all brands), and there the difference between float and double computations is not noticable. In fact, as Fladimir

indicates, floats are expanded to the full length of the corresponding registers anyway. But as long as I don't find the already mentioned reference, most of this in only guessing...

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?

I've asked one of our specialists: In a 64 bit processor, the double registers hold 128 bits. The integer width is 64 bits. The number 64 mostly indicates the width of the data bus, so there's no reason why a 32 bit processor can't have 64 bit registers (as are the double registers in a P4 processor), but could have even more. I don't know about the MME or SSE registers, I'll try to find some references today.

How many bits does AGP have? And PCIe? I thought it was 128 bits, so you could push 4 integers from CPU to the GPU in 1 cycle!

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.

To my understanding a double register is just two normal registers which you can use for a limited number of things. If there are assembler directives which can handle double register arithmetic then those directives takes twice as long to execute as the ones which uses normal registers. Is that wrong?

In my book on Microprocessors it says that it's mostly the register width which is used to classify a processor as X-bit.

I rather read what someone here who knows this stuff has to say. I've only taken one Microprocessor course as I study CS. But there are lots of people here with good knowledge of hardware. Let's hope they pop up.

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.

The MMX registers are often the same as the floating point registers (at least, they used to be). That's why if you're doing MMX calculations, you can't do any floating-point calculations before you've called EMMS.

But yeah, I remembered wrong. The size of the FP register is 80 bits. But the same registers are used with both floats and doubles, so there's no difference in calculation speed.

I think I'll write a small test program for this. From what I've read this morning it might well be possible that the instructions of the P4 can specifiy how many of those 80 bits to use for calculations, as there are 3 different float formats possible for each register: 32 bit, 64 bit (double, same as MMX/SSE) and 80 bit (double extended precision). So it might be possible that multiplying two floats can be a little faster than multiplying two doubles.

I guess though, that the impact of this is small compared to the effects of pipelining instructions and branch predicition, as well as what is refered to as 'changing mode' of the fpu registers. This suggests (as is also recommended in the Optimization Guide) that you stick to one particular floating format and don't mix different bit length.

Maybe. Which is why I think it's mainly a bandwidth issue.

For 387 registers, the 32 bit float, 64 bit double or whatever is always treated as an 80 bit long double unless the precision in the control word has been altered from the default (which gcc does for compatibility for some old and IMAO broken programs). This is after loading the number from memory of course. IIRC, a double can be slower if it crosses some certain boundary, and of course if you're using an array bigger than cache size you're wasting a lot of time.

You can't take those Intel docs too seriously, back in the '90's I had an 8086/8087 Intel book of some kind, and it said the 8087 sped up floating point calculations from "10 to 100 times faster", but eventually I got an XP and clone 286 and my asm floating point stuff was faster on the 286 (fpu slowed down to 2/3 cpu speed) and only slightly slower on the XP (8 bit bus). Except for trancendentals of course