[NXC] convert float to int

[HaWe]

Technically, the round() method is usually implemented as such:

Code: Select all

inline long round(float x)
{
    return(x + 0.5);
}

I think I misunderstood:
you don't mean: usually implemented already in NXC, did you?
I have been searching but couldn't find a "round method" in NXC.

but muntoo, no, you're wrong with your formula, try it by yourself with negative values.
round is usually implemented as

Code: Select all

inline long round(float f)
{
  if (f>=0) return (f + 0.5);
  else  return (f - 0.5);
}

[muntoo]

you don't mean: usually implemented already in NXC, did you?

Nope.

but muntoo, no, you're wrong with your formula, try it by yourself with negative values.

Not wrong, just biased.
Boost Implementations

I'm not sure how NXC handles implicity conversions from float->int, so I'll rewrite it with floor():

Code: Select all

float round(float x)
{
    return(floor(x + 0.5));
}

Tests:

Code: Select all

round( 3.1)    3
round( 3.5)    4
round( 3.9)    4
round( 0.5)    1
round( 0.0)    0
round(-0.1)    0
round(-0.5)    0
round(-0.6)   -1
round(-1.1)   -1
round(-1.5)   -1
round(-1.9)   -2

That should be "accurate" enough, right?

-----

If you've got CPU to waste, you can use:

Code: Select all

float round(float r) {
    return (r > 0.0) ? floor(r + 0.5) : ceil(r - 0.5);
}

[HaWe]

why so complicated and use functions inside a function?
this is the fastest code and as accurate as possible:

Code: Select all

inline long round(float f)
{
  if (f>=0) return (f + 0.5);
  else  return (f - 0.5);
}

or, nested:

Code: Select all

inline long round(float f)
{
   return (f>=0? f+0.5 : f-0.5);
}

provided or implied assiociativity is
round(-x)= -(round(x));
so should be
round(-0.5)=-1
round(-1.5)=-2
a.s.o.

[muntoo]

why so complicated and use functions inside a function?

As I said, I'm not sure about float->int conversions in NXC, so this could potentially be used instead:

Code: Select all

inline long round(float x)
{
    return(x + 0.5);
}

With greater speed and "accurate-enough-accuracy".

[HaWe]

no muntoo, don't be blase and narrow-minded, your formula is wrong for negative values!
see it at last!
And if you're not sure: test it (or simply believe it to me.)
this is valid:

Code: Select all

inline long round(float f)
{
   return (f>=0? f+0.5 : f-0.5);
}

[muntoo]

Code: Select all

inline long round(float f)
{
   return (f>=0? f+0.5 : f-0.5);
}

Does this mean int(-0.1) == 0? Otherwise, if int(-0.1) == -1, then round(-0.1) == -1, using your method.

EDIT: It indeed is int(-0.1) == 0.

The fractional part is discarded. In other words, conversion from a floating-point type to an integer type truncates.

Also, "right/wrong" really depends on your definition of it, what you're trying to do, and what you actually need. But, yeah, your formula should be the "correct" one for what you believe is correct.

[HaWe]

what's mathematically right or wrong is not decided by me or by you but by the mathematic laws and axioms or definitions.
but you may believe what you want, you are not forbidden to believe wrong facts.

Indeed "my" round() function returns for -0.1 => 0 and e.g. for -0.6 => -1
you might have seen that if you had tried.

And now let's stop the altercation.

[gloomyandy]

Hi Doc,
Although your definition may be mathematically correct your interpretation is not the same as that used my many floating point libraries. So for instance Java (and lots of other languages) defines round as:
(long)Math.floor(a + 0.5d)
http://download.oracle.com/javase/6/doc ... nd(double)

Which means that round(-0.5) is 0 not -1 (it would be -1 with your definition)...

I thought I would just give you another reason to hate Java...

Andy

PS There is a good discussion of the various issues here:
http://en.wikipedia.org/wiki/Rounding
if anyone is interested

[HaWe]

no, you didn't :)
the -0.5 rounding is indeed interpreted differently, but that's not the point.
If -0.49999999999... is rounded to 0 and -0.5 to -1
or
-0.5 is rounded to 0 and -0.500000000000....1 to -1
that's not a mathematic problem but just a convention and the result depends maybe only on the binary floating point notation of -0.5 and it's precision .
(is 0.99999999999999999... as a fp value ==1 ? mathematically, it is, of course, but you won't get this equation with computers probably...)

Some define a rounding from every exact i+ 0.5 (for all integer i either positive or negative) as the next bigger integer number (i+1).
the symmetric associative definition
round(-x)=-round(x)
is nevertheless more logical, but who said that Java programmers do think logically?^^
(Not even C programmers do it always and continuously.)