None <Non### [at] onca> wrote in news:Xns### [at] 204213191226:

> Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in 
> news:Xns### [at] 204213191226:
> 
>> Since f_r() is a built in function in POV-Ray, it should be a
>> little bit faster. But I doubt that you will be able to measure
>> any significant speed increase with it in your macros.
>> [...]
> 
> Thanks for clearing that.  Oh, and just in case you may think I'm not 
> reading your suggestions (after that ln() thing), I feel I need to 
> explain why I opted not to use some of your suggestions:
> 
> Let's take for example:
>   #if (R > 0)
>     #local S = sin(R)/R;
>   #else
>     #local S = 0;
>   #end // if
> 
>   (Et*<S*Q.x, S*Q.y, S*Q.z, cos(R)>)
> 
> I've decided to leave it as:
>   #if (R > 0)
>     #local S = ET*sin(R)/R;
>   #else
>     #local S = 0;
>   #end
>   <S*Q.x,S*Q.y,S*Q.z,ET*cos(R)>
> 
> Simply for performance issues.  I realize it's not much, but the first 
> one will have two more multiplications if R>0 and will have three more 
> multiplications if R <= 0.  And perhaps, it's simply a coding style as 
> well.
> 
> But I do appreciate any and all input, it helps.

I see what you mean. - But I have experienced that
the number of mathematical operations within POV-
Ray macros is not necessarily a good measure for
how fast or slow the macros will be. (Maybe this is
because it is a parsed languge ;-)

While coding I sometimes tend to sacrifice a little
performance in attempts to get more elegant code.

(If the problem is very complex I always go for
readability and elegance. This makes it easy to
discover bugs. Although this often makes the code
grow for a while, it makes it easy for me in the
later stages to see how it can be simplified and
shaved down to a minimum.)


Tor Olav

Post a reply to this message