Inacurate precision truncating.

Thanks folks,
I used Dan's method, it will definitely work for my situation. I know for sure my floating point is always positive numbers.
Neither floor() nor ceil() will not solve the problem.

y = floor(3.53);
y will be 3, which is should be 4.
The round off should occur at 0.4 or 0.5
Unless my definition of round off is different than others.

Thanks folks,
I used Dan's method, it will definitely work for my situation. I know for sure my floating point is always positive numbers.
Neither floor() nor ceil() will not solve the problem.

y = floor(3.53);
y will be 3, which is should be 4.
The round off should occur at 0.4 or 0.5
Unless my definition of round off is different than others.

My understanding is:

Rounding off should round to the nearest integer;
Rounding down should round to the nearest integer below (ie, floor);
Rounding up should round to the nearest integer above (ie, ceil)

So:
for positive values, truncation is equivalent to rounding down;
for negative values, truncation is equivalent to rounding up;
for negative values, you would round off by subtracting the 0.5.

What about y = ceil(3.53); ?

So maybe he could do this:

int y = floatVar < 0.0 ? floor(floatVar) : ceil(floatVar);

Using the float type definition from your original post and assuming that the range of float input fits in an integer, I'd consider something like:

int round( fsingle fVal )
{
    return ((int)(fVal + ((fVal < 0.0) ? -0.5 : 0.5)));
}

I can't see with all the parenthesis!

:-)

int round(fsingle fVal)
{
    return (int) (fVal + fVal < 0.0 ? -0.5 : 0.5);
}

Good to see people who aren't afraid of the Ternary Operator!

No, precedence is your friend; explicitness is my friend.

:-)

Over the years, and especially working with clients having pre-existing code, I've found (for me at least) that it's best not to pick nits over stylistic differences. To each his (or her) own. So, while I generally appreciate your informed posts, I won't engage you in discussing our sylistic differences.

Keep up the good work. We all appreciate your help around here.

--Dan Henry

I was definitely just ribbing you. I agree, to each his own.

- Mark

Indeed, I always tell people who say it obfuscates code that var++; is very odd at first glance as is var += value; ?: is very, very clear once the idiom is learned just as are var++ and var += value.

Long live all parts of the the C language.

Example use #234 of ?:...

int cash = 1;
printf("You have %d dollar%s\n", cash, 1 == cash ? "" : "s");

Of course this would have worked just as well I suppose:

int cash = 1;
char dollarStr[][sizeof "dollars"] = { "dollars", "dollar" };

printf("You have %d %s\n", cash, dollarStr[cash == 1]);

True that folks, there is no need to talk about programming styles.
In general, our team follow some sort of programming style pattern. This is due to programming skill differences among team members. So in general, making the program source code as explicitly as possible so that there is no misunderstanding and in addition, the C compiler will be smart enought to optimize "all" redundency.

"the C compiler will be smart enought to optimize "all" redundency."

You'd hope so, wouldn't you?

I did once come across a compiler (not 8051; not Keil; someone beginning with 'I') which did produce different results if you used "unnecessary" parentheses!

But then their assembler produced the same opcode for both the "Jump If Equal" and "Jump If Not Equal" mnemonics!!