POV-Ray : Newsgroups : povray.programming : cycloidal()? Server Time: 11 Mar 2014 14:19:29 GMT
 cycloidal()? (Message 1 to 5 of 5)
 From: Christopher James Huff Subject: cycloidal()? Date: 7 Jan 2005 03:32:43 Message:
```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 <cjameshuff [at] earthlinknet>
POV-Ray TAG: <chris.huff [at] tagpovrayorg>
http://tag.povray.org/
```
 From: Thorsten Froehlich Subject: Re: cycloidal()? Date: 7 Jan 2005 10:03:13 Message: <41de5e61\$1@news.povray.org>
```In article <cjameshuff-9CA1F9.22323806012005@news.povray.org> , Christopher
James Huff <cjameshuff [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: thorsten [at] trfde

Visit POV-Ray on the web: http://mac.povray.org
```
 From: Warp Subject: Re: cycloidal()? Date: 7 Jan 2005 10:16:07 Message: <41de6167@news.povray.org>
```Thorsten Froehlich <thorsten [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 -
```
 From: Christopher James Huff Subject: Re: cycloidal()? Date: 11 Jan 2005 20:47:34 Message:
```In article <41de5e61\$1@news.povray.org>,
"Thorsten Froehlich" <thorsten [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
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

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 <cjameshuff [at] earthlinknet>
POV-Ray TAG: <chris.huff [at] tagpovrayorg>
http://tag.povray.org/
```
 From: Andrew the Orchid Subject: Re: cycloidal()? Date: 16 Jan 2005 14:41:39 Message: <41ea7d23\$1@news.povray.org>
```>>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...
```