rounding up or down to .5

[Kieron]

Help...

I need to round a number up or down to the nearest 0.5. I have tried using the round function, but it will only round to a decimal place not halves.

e.g 12.3456 --- 12.5 and 173.76132 ---- 174

I have tried rounding to 2 decimal places and then depending on the last digit change to number using text function. I'm sure there must be an easier way, but I can't seem to do it.

Kieron

[LiveOak]

Try this:

RoundedNumber (calculation, number) =

Int (number)

+

Case (

Mod (number, 1) < .25, 0,

Mod (number, 1) < .75, .5,

1)

-bd

[slstrother]

Here is another method, found at FM Techinfo

Int(Number*2+.499999)/2

Steve

[Lee Smith]

Hi Kieron,

Not intending to step on LiveOaks toes or anything, but here are a couple more calculations:

Int(number) + Int(( Mod(number, 1) + .49) * 2 )/2

(Int(2*number) + Sign(number)*(Mod(2*number,1)!=0))/2

HTH

Lee

[LiveOak]

Which calculation will be fastest??? -)

-bd

[Lee Smith]

Don't know.

Don't Care.

:o

[-Queue-]

And

Let( T = Int(4 * Mod( num; 1 )); Int(num) + .5 + .5 * (T = 3) - .5 * (not T) )

or

Int(num) + Choose( Int(4 * Mod( num; 1 )) - 1; .5; .5; 1 )

Too many fun methods from which to choose.

[comment]

I suppose

Round (2 * InputNumber ; 0) / 2

would be too simple?

[Barbecue]

OHO! An opportunity for me to do some benchmarking!

[Barbecue]

I generated 20,000 random numbers, and ran each algorithm ten times against each number for a total of 200,000 iterations. I implemented each function as a set field script step. I did not generate custom functions, because my informal experiments tend to indicate that a custom function seems to have slightly more overhead than a script step.

Algorithm          ET      O      F

comment        0:01:35     2      1

slstrother       0:01:36     3      1

Lee 1             0:02:00     4      3

-queue- 2      0:02:03     2      3

-queue- 1      0:02:16     7      4

Lee 2            0:02:20     6      3

LiveOak        0:03:00     3      4

Conclusions:

1. The simpler algorithms ran faster than the more complicated ones. Nothing surprising about that.

2. Function calls seem to incur more overhead than operators. The number of operators used in the algorithm appears to have less impact on the overall speed than the number of function calls did.

3. I need to get out more.

[comment]

Er... I would like to thank the Members of the Academy...

[comment]

On a more serious note: speed may be important, but correct results should come first.

This calculation (1st runner-up):

Int(Number*2+.499999)/2

incorrectly returns 0 (instead of 0.5) when Number=0.25;

This calculation (2nd runner-up):

Int(number) + Int(( Mod(number, 1) + .49) * 2 )/2

rounds UP, i.e. when Number=0.1, the result returned is 0.5.

However, when Number=0.09 or less, the result will be 0.