On Wed, 27 Sep 2006 20:44:05 +0100, Orchid XP v3 wrote:

> My particular function was something like x^18 + ... = 0. It has almost 
> vertical sides, yet the "interesting" part has a tiny derivative. My 
> using the log() function I can "magnify" the interesting bit, and zoom 
> out the unimportant vertical walls that are confusing the poor root solver.
> 
> However, note that you must make sure the function is NEVER NEGATIVE, 
> since log(-1) is a complex number, and POV-Ray won't like that. This 
> sometimes requires you to translate the function in the Y-direction, 
> take the log, and then translate the result back again:
> 
>    f2(x) = k + log(f1(x) - k)
> 
> Selecting the correct k turns out to be very critical. The log function 
> shrinks large features, but it can also "magnify" small ones. If you get 
> the "wrong" value for k, you can end up creating big vertical side RIGHT 
> NEXT TO THE ZEROS. That means you MUST use a high max_gradiant or 
> POV-Ray will overshoot the zeros - the exact thing we were trying to 
> avoid...

Yeah, the magnification of small values (which also applies to, say,
sqrt(x)), is something I forgot about.  I guess real world functions would
be less trivial to "map" in the sense I was talking about.

> (The problem gets even more fun if you start taking double-logs!)

Why would you want to do that for a function other than a
double-exponential?  Masochism? Maths fetish? :)

>> I'm curious, could this kind of thing theoretically be done
>> automatically by povray?  What if it were to use log(function) or
>> sqrt(function) or 1/function to find the surface points rather than the
>> actual function, and the max_gradient were to apply to that function
>> instead of the original?
> 
> For every function for which this is faster, there is another one for
> which it is slower. It would probably take more time to detect which
> case applies than to just use the "wrong" variant. (See above.)
> 
> OTOH, it might be worth making a *keyword* to do this kind of
> optimisation automatically instead of altering the function by hand...

Also, I just realised, I think most functions with ever-increasing
gradients could be reined in by putting it in a min() or max() function,
or both.  Would that work with your exp function?

Mick.

-- 
Remove the -news from my email address.
http://mickworld.knobbits.org/

Post a reply to this message

Michael (Micksa) Slade nous apporta ses lumieres en ce 28/09/2006 09:20:
> On Wed, 27 Sep 2006 20:44:05 +0100, Orchid XP v3 wrote:
> 
>> My particular function was something like x^18 + ... = 0. It has almost 
>> vertical sides, yet the "interesting" part has a tiny derivative. My 
>> using the log() function I can "magnify" the interesting bit, and zoom 
>> out the unimportant vertical walls that are confusing the poor root solver.
>>
>> However, note that you must make sure the function is NEVER NEGATIVE, 
>> since log(-1) is a complex number, and POV-Ray won't like that. This 
>> sometimes requires you to translate the function in the Y-direction, 
>> take the log, and then translate the result back again:
>>
>>    f2(x) = k + log(f1(x) - k)
>>
>> Selecting the correct k turns out to be very critical. The log function 
>> shrinks large features, but it can also "magnify" small ones. If you get 
>> the "wrong" value for k, you can end up creating big vertical side RIGHT 
>> NEXT TO THE ZEROS. That means you MUST use a high max_gradiant or 
>> POV-Ray will overshoot the zeros - the exact thing we were trying to 
>> avoid...
> 
> Yeah, the magnification of small values (which also applies to, say,
> sqrt(x)), is something I forgot about.  I guess real world functions would
> be less trivial to "map" in the sense I was talking about.
> 
>> (The problem gets even more fun if you start taking double-logs!)
> 
> Why would you want to do that for a function other than a
> double-exponential?  Masochism? Maths fetish? :)
> 
> Mick.
> 
You can come acros functions that have even more extreem gradients and a single 
log still give you a max_gradient in the thousands, like a 20th degree or more 
or an x^10x kind of case. You then may want to use double logs. In that case, it 
can be usefull to use log(max(0, log(YourFunction))) to clip negative values.

-- 
Alain
-------------------------------------------------
If That Phone Was Up Your Butt, Maybe You Could Drive A Little Better!

Post a reply to this message

I suppose you could try using the evaluate keyword instead of just giving
max_gradient...  go with evaluate 1e+17,3,0.1 or so, and maybe it'd run at
a decent speed (if you're lucky) without mucking about with renormalizing
the function.

Post a reply to this message

> I suppose you could try using the evaluate keyword instead of just giving
> max_gradient...  go with evaluate 1e+17,3,0.1 or so, and maybe it'd run at
> a decent speed (if you're lucky) without mucking about with renormalizing
> the function.

The evaluate keyword is only for figuring out what max_gradient should 
be optimally set to. It doesn't change the need to make the function 
*reasonably* well behaved to get good performance...

Post a reply to this message