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.0-sin((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/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <cjameshuff-9CA1F9.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 floating-point
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
e-mail: tho### [at] trfde

Visit POV-Ray 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 floating-point
> 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 floating-point
> 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 sine-wave, 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/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

>>or the code is trying to play with floating-point
>>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