





 
 




 
 


Could someone explain the construction of this function to me? (Found in
texture.cpp)
DBL cycloidal(DBL value)
{
if (value >= 0.0)
{
return sin((DBL) (((value  floor(value)) * 50000.0)) / 50000.0
* TWO_M_PI) ;
}
else
{
return 0.0sin((DBL) (((0.0  (value + floor(0.0  value))) *
50000.0)) / 50000.0 * TWO_M_PI);
}
}
Is there some point to multiplying the value by 50000 and then dividing
it by the same value?
And then, for negative values, it does weird things to the input to
sin() and then negates the result...
The two expressions simplify to:
sin((value  floor(value)) * TWO_M_PI)
and:
sin((value + floor(value)) * TWO_M_PI)
So, near as I can tell, the function does the same thing as this:
DBL cycloidal(DBL value)
{
return sin(fmod(value, 1)*TWO_M_PI);
}
So...why? Why all the code to avoid the fmod() function, and why that
weird multiplication and division above?

Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POVRay TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message


 
 




 
 


In article <cjameshuff9CA1F9.22323806012005@news.povray.org> , Christopher
James Huff <cja### [at] earthlinknet> wrote:
> So...why?
Depending on the history of the code it is either stupidity or brilliance.
It could just be the result of many changes that made the function the way
it is now (stupidity), or the code is trying to play with floatingpoint
accuracy in a complex way (brilliance). It is impossible to tell without
comparing the function and its simplified twin over a significant range of
input values.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
email: tho### [at] trfde
Visit POVRay on the web: http://mac.povray.org
Post a reply to this message


 
 




 
 


Thorsten Froehlich <tho### [at] trfde> wrote:
> or the code is trying to play with floatingpoint
> accuracy in a complex way (brilliance).
It's not brilliant if the idea is not commented in any way.

#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)6mod(div(D,13)8)3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  Warp 
Post a reply to this message


 
 




 
 


In article <41de5e61$1@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trfde> wrote:
> Depending on the history of the code it is either stupidity or brilliance.
> It could just be the result of many changes that made the function the way
> it is now (stupidity), or the code is trying to play with floatingpoint
> accuracy in a complex way (brilliance). It is impossible to tell without
> comparing the function and its simplified twin over a significant range of
> input values.
My vote is for a weird hack to get correct results in some old compiler,
and simple neglect accounting for the lack of documentation. (Judging
from the comments in leopard_pattern(), some of the compilers used were
pretty bad.)
The result is a simple sinewave, either way...I see no way for it to
produce visibly different results, if the math library performs as
advertised.
Really, since it's used only to get a sinusoidal curve, a relatively
inaccurate polynomial approximation or a linearly interpolated look up
table might give good enough results.
Oh, I goofed slightly...the function I gave was what I think the author
was trying to accomplish, but the most simplified version is really:
DBL cycloidal(DBL value)
{
return sin(value*TWO_M_PI);
}
Not really worth having a function devoted to it. Maybe the original was
supposed to fix a sin() function that misbehaved with negative or large
inputs. Maybe fmod() misbehaved too, or the author didn't know about it.
How about the following comment in onion_pattern()?
/* The variable noise is not used as noise in this function */
My question here is pretty obvious. Was there some kind of limit on the
number of identifiers that could be used?
Ouch...just found out that the agate, marble, spiral, and wood patterns
loop through all applied warps (including ordinary transformations) just
to find the last one and use it internally if it is a "classic
turbulence" warp. They always loop through all the transformations, for
every evaluation.

Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POVRay TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message


 
 




 
 


>>or the code is trying to play with floatingpoint
>>accuracy in a complex way (brilliance).
>
>
> It's not brilliant if the idea is not commented in any way.
*grins*
Good point...
Post a reply to this message


 
 




 