POV-Ray : Newsgroups : povray.newusers : rounding Server Time
28 Jul 2024 20:27:18 EDT (-0400)
  rounding (Message 11 to 20 of 26)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 6 Messages >>>
From: Chris B
Subject: Re: rounding
Date: 26 Jun 2008 04:06:18
Message: <48634dfa$1@news.povray.org>
"Warp" <war### [at] tagpovrayorg> wrote in message 
news:486340c6@news.povray.org...
>  Unrelated to this topic in particular, but related to rounding. There's
> a curious anecdote about rounding in FPUs:
>
> ... most FPUs simply clamp those bits away, period, without
> any kind of rounding.
> ...
>  In some FPU ... they ... round the value up or down *randomly*.... the 
> rounding
> errors caused by the regular clamping method were significant, the random
> method caused much smaller rounding errors.
> ...
> 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.

But a result which is not necessarily the same each time you calculate the 
answer using the same dataset as input.

Regard,
Chris B.


Post a reply to this message

From: Warp
Subject: Re: rounding
Date: 26 Jun 2008 05:06:34
Message: <48635c1a@news.povray.org>
Chris B <nom### [at] nomailcom> wrote:
> But a result which is not necessarily the same each time you calculate the 
> answer using the same dataset as input.

  You should never rely on getting an exact result when calculating with
floating point numbers anyways.

-- 
                                                          - Warp


Post a reply to this message

From: Chris B
Subject: Re: rounding
Date: 26 Jun 2008 07:16:02
Message: <48637a72$1@news.povray.org>
"Warp" <war### [at] tagpovrayorg> wrote in message 
news:48635c1a@news.povray.org...
> Chris B <nom### [at] nomailcom> wrote:
>> But a result which is not necessarily the same each time you calculate 
>> the
>> answer using the same dataset as input.
>
>  You should never rely on getting an exact result when calculating with
> floating point numbers anyways.
>

No, but, a computer that doesn't give the same results when you run an 
algorithm twice in a row would be hell to debug. So you'd expect 'if 
(1/3=1/3)' to always give the same answer, not true half the time and false 
the other half.

Regards,
Chris B.


Post a reply to this message

From: Jan Dvorak
Subject: Re: rounding
Date: 26 Jun 2008 08:14:01
Message: <48638809$1@news.povray.org>
Chris B napsal(a):
> "Warp" <war### [at] tagpovrayorg> wrote in message 
> news:48635c1a@news.povray.org...
>> Chris B <nom### [at] nomailcom> wrote:
>>> But a result which is not necessarily the same each time you calculate 
>>> the
>>> answer using the same dataset as input.
>>  You should never rely on getting an exact result when calculating with
>> floating point numbers anyways.
>>
> 
> No, but, a computer that doesn't give the same results when you run an 
> algorithm twice in a row would be hell to debug. So you'd expect 'if 
> (1/3=1/3)' to always give the same answer, not true half the time and false 
> the other half.
> 
> Regards,
> Chris B. 
> 
> 
I've got another idea: force the LSB to 1. If it was 0 the result is 
rounded up. If it was 1 the result is rounded down.
This emulates the randomness in a deterministic way.

-- 
You know you've been raytracing too long when...
you start thinking up your own "You know you've been raytracing too long 
when..." sigs (I did).
		-Johnny D
Johnny D


Post a reply to this message

From: Warp
Subject: Re: rounding
Date: 26 Jun 2008 10:07:28
Message: <4863a2a0@news.povray.org>
Chris B <nom### [at] nomailcom> wrote:
> No, but, a computer that doesn't give the same results when you run an 
> algorithm twice in a row would be hell to debug. So you'd expect 'if 
> (1/3=1/3)' to always give the same answer, not true half the time and false 
> the other half.

  You'd also expect (0.1*10.0 == 1.0) to give true, but it probably doesn't.

-- 
                                                          - Warp


Post a reply to this message

From: Slime
Subject: Re: rounding
Date: 27 Jun 2008 01:52:48
Message: <48648030@news.povray.org>
>> But a result which is not necessarily the same each time you calculate 
>> the
>> answer using the same dataset as input.
>
>  You should never rely on getting an exact result when calculating with
> floating point numbers anyways.


But don't a number of video games, RTS's in particular, rely on getting 
exactly the same results when given the same input? I believe the IEEE 
standard specifies deterministic rounding ( 
http://en.wikipedia.org/wiki/IEEE_754#Rounding_floating-point_numbers ), 
which is probably why they work. Round-to-even has basically the same 
properties as the random method you gave.


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


Post a reply to this message

From: andrel
Subject: Re: rounding
Date: 28 Jun 2008 15:07:33
Message: <48668C29.90908@hotmail.com>
Warp wrote:
> 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.)

you could use ceil(A-0.5) in that case or even use a switch for >0 and <0
> 
>   Why would rounding it to -4 be more correct? 3.5 is equally close to
> either value.
> 
depends on convention. There as thus 4 ways to round halves: 
up,down,towards zero and away from zero.


Post a reply to this message

From: Warp
Subject: Re: rounding
Date: 28 Jun 2008 15:09:51
Message: <48668c7f@news.povray.org>
andrel <a_l### [at] hotmailcom> wrote:
> depends on convention. There as thus 4 ways to round halves: 
> up,down,towards zero and away from zero.

  Actually there's a fifth convention which is also widely used: Round
to the closest even number. I believe the idea behind this one is that
tries to even out systematic bias in lengthy calculations.

-- 
                                                          - Warp


Post a reply to this message

From: andrel
Subject: Re: rounding
Date: 28 Jun 2008 15:17:05
Message: <48668E65.6080306@hotmail.com>
Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> depends on convention. There as thus 4 ways to round halves: 
>> up,down,towards zero and away from zero.
> 
>   Actually there's a fifth convention which is also widely used: Round
> to the closest even number. I believe the idea behind this one is that
> tries to even out systematic bias in lengthy calculations.
> 
Not to mention the university teacher that recommended alternate up and 
down rounding for even less bias ;) . I have seen libraries of functions 
for the four I mentioned but not for this round to even or the 
alternating one or the random one you mentioned earlier.


Post a reply to this message

From: alphaQuad
Subject: Re: rounding
Date: 29 Jun 2008 14:05:00
Message: <web.4867ce3d42ba7542bfec89d20@news.povray.org>
didnt read it. I've seen less complex functions work and not work neagtive-wise,
depending on the sytem. handle negs, int() instead of floor() in POV should
solve the neg issue

#macro round(f,n)
  #local c = floor(pow(10.0,n));
  #local d = 0.5 / c;
  #local d = d + abs(f);
  #local d = d * c;

  #local d=floor(d);
  #local d = d/c;
  #if (f < 0.0) #local d = d * -1; #end
  (dd)
#end

functions rain overkill mode:

#macro incenter(A,B,C)
      #local a = C*vlength(A-B);
      #local b = A*vlength(B-C);
      #local c = B*vlength(C-A);
      #local d = vlength(A-B)+
                 vlength(B-C)+
                 vlength(C-A);
  #local result = (a+b+c)/d;
  result
#end
#macro centroid(A,B,C)
  #local result = (A+B+C)/3;
  result
#end

#macro circumcenter(A,B,C)
      #local a = vlength(A-B);
      #local b = vlength(B-C);
      #local c = vlength(C-A);
      #local sp = (a+b+c)*0.5;

   #local cosineR = ((b*b + c*c - a*a)/(2*b*c))*
      a*b*c/(4*sqrt(sp*(sp-a)*(sp-b)*(sp-c))); //circumradius(A,B,C);
   #local mp = (A+B)/2; //midpoint(A,B)
   #local result = mp+(vnormalize(vcross(A-mp,vcross(C-B,A-B)))*cosineR);
   result
   /* "walks" to cCenter in 3D.
      Algebra core step=cos(angle)*R.
      Input order irrelevant since both (A-mp)
      and norm vectors reverse in sync */
#end

#macro outcenter(A,B,C)
   circumcenter(A,B,C)
#end
#macro ccenter(A,B,C)
   circumcenter(A,B,C)
#end

#macro orthocenter(A,B,C)
      #local a = vlength(A-B);
      #local b = vlength(B-C);
      #local c = vlength(C-A);
      #local sp = (a+b+c)*0.5;

   #local cosineR = ((b*b + c*c - a*a)/(2*b*c))*
      a*b*c/(4*sqrt(sp*(sp-a)*(sp-b)*(sp-c))); //outeradius(a,b,c);
   #local mp = (A+B)/2; //midpoint(A,B)
   #local cc = mp+(vnormalize(vcross(A-mp,vcross(C-B,A-B)))*cosineR);

   #local result = ((A-cc)+(B-cc)+(C-cc)) + cc;
   result
#end

#macro inner_radius(A,B,C)
      #local a = vlength(A-B);
      #local b = vlength(B-C);
      #local c = vlength(C-A);
   #local result = 0.5*sqrt(((b+c-a)*(c+a-b)*(a+b-c)) / (a+b+c));
   result
#end
#macro tetrahedron_volume(A,B,C,D)
  #local result = abs(vdot(D-A,vcross(D-B,D-C))) / 6;
  result
#end
#macro pyramid_volume(A,B,C,D,E)
  // perimeter order for 1st 4 points
  #local result =
     tetrahedron_volume(A,B,C,E) + tetrahedron_volume(A,C,D,E);
  result
#end
#macro triangle_area(A,B,C)
     //2D .z must be 0
   #local result = abs((B.x*A.y - A.x*B.y)+
                       (C.x*B.y - B.x*C.y)+
                       (A.x*C.y - C.x*A.y)) / 2;
   result
#end
#declare inneradius = function(a,b,c) {
   //(3 lens)
   0.5*sqrt(((b+c-a)*(c+a-b)*(a+b-c)) / (a+b+c))
}
#macro circumradius(A,B,C)
      #local a = vlength(A-B);
      #local b = vlength(B-C);
      #local c = vlength(C-A);
   #local result = a*b*c/(4*sqrt(((a+b+c)/2)*(((a+b+c)/2)-a)*
                   (((a+b+c)/2)-b)*(((a+b+c)/2)-c)));
   result
#end

#declare outeradius = function(a,b,c) {
  //(3 lens)
  a*b*c/(4*sqrt(((a+b+c)/2)*(((a+b+c)/2)-a)*(((a+b+c)/2)-b)*(((a+b+c)/2)-c)))
  //(a*b*c) / (4*sss_area(a,b,c))
}

#declare sas_area = function(s,a,s2) {
   0.5 * s * sin(a) * s2
}

#declare sas_cos = function(s,a,s2) {
   sqrt((pow(s,2)+pow(s2,2))-2*s*s2*cos(a))
} // Side Angle Side - solve length of missing side


#declare sas_height = function(s,a,s2) {
    s*sin(a)*s2/sqrt((pow(s,2)+pow(s2,2))-2*s*s2*cos(a))
   //sas_area(s,a,s2) / (sas_cos(s,a,s2) * 0.5)
} // SAS height to missing side


#declare bh_area = function(b,h) {
   //(base,height)
   0.5 * b * h
}

#declare sss_height = function(a,b,c) {
  sqrt(((a+b+c)/2)*(((a+b+c)/2)-a)*(((a+b+c)/2)-b)*(((a+b+c)/2)-c))/(b*0.5)
  //sss_area(a,b,c) / (b * 0.5)
} // height to side2

#declare sss_area = function(a,b,c) {
   //semi perimeter
   sqrt(((a+b+c)/2)*(((a+b+c)/2)-a)*(((a+b+c)/2)-b)*(((a+b+c)/2)-c))
}

#declare vmyv = function {
//function that returns a vector
   transform {
     rotate <0, 0, 0>
     scale 1
   }
}

#declare aas_sin = function(a,b,s) {
   sin(b) * (s / sin(a))
} // AAS solve opposing side of angle2 (b)

#declare asa_sin = function(a,s,b) {
   sin(b) * (s / sin(pi-(a+b)))
} // ASA solve opposing side of angle2 (b)

#declare sss_cos = function(a,b,c) {
   acos((pow(a,2)+pow(c,2)-pow(b,2))/(2*a*c))
} // SSS solve angle opposite side2 (b)
  // if (pow(a,2)+pow(c,2)-pow(b,2))/(2*a*c) < 0 obtuse

#declare ssa_acute = function(s,s2,a) {
   asin(s2*sin(a)/s)
} // SSA solve angle opposite side2

/*
alias sss_area2 {
  ; (3 lens)
  return $calc(0.5 * ($1 + $2 + $3) * $inneradius($1,$2,$3))
}
alias sss_area3 {
  ; (3 lens)
  return $calc(($1 * $2 * $3) / (4 * $circumradius($1,$2,$3)))
}*/


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 6 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.