casting from float to double

if you're going to cast it, cast it sooner to keep most of your program with floats so not to confuse people and also to avoid copying the larger value around...

cast it - what else are you going to do?

my opinion - exacty the same type of code will be executed for

xpos += (float)GetXComponent( (double)myangle );

as

xpos += GetXComponent( myangle );

( cast to double - get cos of - cast to float )

but which looks nicer to type repeatadly and encapsulates what you're doing better

I was under the impression that upward coercion was free. Double's only slowness being that its larger than the natural word size.

If you feel the coersions are a bottleneck, try overloading the function. Then, let the compiler choose the faster one for you.

public float  GetXComponent(float  Angle);public double GetXComponent(double Angle);

I would recommend returning the double because

a) you can always optimize it later.
b) Yes, there will be two casts either way assigning to a float, but if the caller happens to assign to a double, now there are three casts instead of one - plus you lose precision.
c) AFAIK, you don't need to write the cast explicitly in the calling code, even in Java. (Although I'm sure there are languages where you do. Ada? Pascal?)

I would recommend passing in a double because

a) there will be an implicit upcast exactly once when you pass in a float, somewhere along the line, no matter how you do it.
b) by taking a float argument, you lose the ability to pass in doubles, and will end up doing two casts (one of which is explicit - and loses precision) when you pass it in as a float.

Although in the example, the function could just as easily be static (since there is no use of class members), and in fact could just as easily be inlined manually everywhere - the function basically just gains you a name for the procedure, at the moment. Although I'm sure you just meant it as a toy example anyway :)

(In normal environments, optimization isn't a real concern here because the JIT will do the inlining at runtime anyway - but on mobile, where every byte counts and that includes bytes in the .jar file... eh, even then, worry about it later rather than sooner; it's better for your sanity :) )