I'm surprised (and a bit pissed off) not to find a means to round a number to
the nearest integer.
I want to use the rand() function to randomly generate a rotation angle which is
a multiple of 90 degrees, which I would write in any programming language I know
as

  RotAngle = 90 * round(4 * rand(RandSeed))

How should I do this in POV-Ray?
TIA
Steven

Post a reply to this message

On Wed, 25 Jun 2008 05:11:06 EDT, "stevenvh" <nomail@nomail> wrote:

>I'm surprised (and a bit pissed off) not to find a means to round a number to
>the nearest integer.
>I want to use the rand() function to randomly generate a rotation angle which is
>a multiple of 90 degrees, which I would write in any programming language I know
>as
>
>  RotAngle = 90 * round(4 * rand(RandSeed))
>
>How should I do this in POV-Ray?
>TIA
>Steven
>

There is 
ceil(A) Ceiling of A. Returns the smallest integer greater than A.
Rounds up to the next higher integer.

And

floor(A) Floor of A. Returns the largest integer less than A. Rounds
down to the next lower integer.

And you can use A - int(A) to see if the fractional part is > 0.5

-- 

Regards
     Stephen

Post a reply to this message

Thanks Stephen!

Post a reply to this message

"stevenvh" <nomail@nomail> wrote:
>   RotAngle = 90 * round(4 * rand(RandSeed))
>
> How should I do this in POV-Ray?


Trevor Quayle posted this helpful function a while ago that rounds 'a' to the
nearest 'b' decimal places:


#declare Round=function
(a,b){select(a,-1,1)*int(abs(a)*pow(10,b)+0.5)/pow(10,b)}



The original is here:

http://news.povray.org/povray.advanced-users/thread/%3Cweb.4739e4827567ddbb94e61a50@news.povray.org%3E/

- How

Post a reply to this message

"How Camp" <hac### [at] gmailcom> wrote:
> The original is here:
>
>
http://news.povray.org/povray.advanced-users/thread/%3Cweb.4739e4827567ddbb94e61a50@news.povray.org%3E/

Wow, I mangled that.  :)

Post a reply to this message

stevenvh nous illumina en ce 2008-06-25 05:11 -->
> I'm surprised (and a bit pissed off) not to find a means to round a number to
> the nearest integer.
> I want to use the rand() function to randomly generate a rotation angle which is
> a multiple of 90 degrees, which I would write in any programming language I know
> as
> 
>   RotAngle = 90 * round(4 * rand(RandSeed))
> 
> How should I do this in POV-Ray?
> TIA
> Steven
> 
> 
> 
> 
> 
Try this:
RotAngle= 90 * int(4 * rand(Seed))

The int() function return the integer part of a float argument.

-- 
Alain
-------------------------------------------------
Drive A: not responding.. .Formating C: instead

Post a reply to this message

> floor(A) Floor of A. Returns the largest integer less than A. Rounds
> down to the next lower integer.
>
> And you can use A - int(A) to see if the fractional part is > 0.5

Or just

floor( A + 0.5 )

(Although this will cause -3.5 to be rounded to -3, which I'm not sure is 
correct.)

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Slime <fak### [at] emailaddress> wrote:
> floor( A + 0.5 )

> (Although this will cause -3.5 to be rounded to -3, which I'm not sure is 
> correct.)

  Why would rounding it to -4 be more correct? 3.5 is equally close to
either value.

-- 
                                                          - Warp

Post a reply to this message

>  Why would rounding it to -4 be more correct? 3.5 is equally close to
> either value.

There's an arbitrary rule that you round up for .5, according to my third 
grade teacher. =) I just mentioned that in case it's something someone cares 
about. It doesn't bother me because I've never encountered a practical 
situation where it mattered.

However, I've always assumed the reason for the rule was that the original 
number might have been truncated from something higher than the .5 value, 
like .53. I suppose this *could* be a practical consideration if your input 
is from a user who might have truncated the number.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Unrelated to this topic in particular, but related to rounding. There's
a curious anecdote about rounding in FPUs:

  As we all know, FPUs have, naturally, a limited number of bits to
represent floating point values. This, of course, means that if more
binary decimal places would be needed to represent the result of an
operation than is available in an FPU register, the lowest decimals
are simply dropped off.

  Now this of course raises the question of what to do with the
least-signifant bit when this happens. The most correct way would be,
of course, to round the number properly, so the least-significat bit
gets a rounded value depending on the even-less-significant bits of
the calculation which were dropped off. (And in fact, other bits may
be changed because of this rounding as well.)

  But this requires quite a lot of extra logic. It would mean that the
FPU has to actually calculate the value with at least a few bits more
precision than the size of an FPU register, and round accordingly.
This would require a lot more logic, make the FPU a lot more complicated
and expensive, increase power requirements, increase heat production, etc.

  For this reason most FPUs simply clamp those bits away, period, without
any kind of rounding. It's the most cost-effective thing to do, and the
error produced is, after all, very small. However, this still introduces
small rounding errors with lengthy calculations which use and reuse
values from earlier calculations.

  In some FPU (I really can't remember which) they tried something a bit
different: Round the value up or down *randomly*. In other words, instead
of calculating extra bits of the result, just randomly assume that the
value needs to be rounded up or down.

  Curiously, when they tested this with applications where the rounding
errors caused by the regular clamping method were significant, the random
method caused much smaller rounding errors.

  The reason is rather logical: When you consistently clamp the lowest
bits away, you are introducing a bias to the results: All results will
be rounded towards zero, and with lengthy calculations all results will
start slowly drifting because of this. However, with random rounding the
bias is averaged away. Assuming that approximately half of the results
would indeed have to be rounded down and the rest up, the random rounding
produces, with lengthy calculations, a result which is much closer to the
correct one.

-- 
                                                          - Warp

Post a reply to this message