clipka <nomail@nomail> wrote:
> The OP was all about "fixing" that *macro*.

> I told him it is fundamentally impossible to "fix", and explained why that is
> so.

  Why would it be impossible to fix? Just change it to calculate the
direction from the derivative functions.

  Very laborious and impractical to change the macro to do so (for dubious
benefit)? Yes. Impossible? Definitely not.

> Calculus is not the problem. Getting the type of function and parameters out of
> POV-Ray and into SDL is.

  Requires a bit of digging the povray source code, resolving the partial
derivatives of the spline function, and implementing these derivatives in SDL.
Laborious? Yes. Impossible? No.

> There *IS* an interface to get f[P](x) out of POV-Ray into SDL, where f is the
> spline function and P are the parameters (i.e. control points).

> There is *NOT* an interface to get an exact f'[P](x) out of POV-Ray into SDL. (I
> don't believe the f' are even coded into POV-Ray.)

  So what? Just implement that "interface" in SDL. Write the derivative
functions in SDL.

> There is *NOT* an interface to get the generic formula for f out of POV-Ray into
> SDL (i.e. you don't know if f is a linear spline, cubic spline, akima spline or
> what-have-you).

  The macro can be told by the user what type of spline it is.
Practical? No. Impossible? No.

> There is *NOT* an interface to get the actual values of P out of POV-Ray.

> => There is *NOT* an interface to get anything out of POV-Ray to compute f'[P],
> hence there is *NOT* a way to compute an exact value of f'[P](x).

  There is no interface to know how the random number generator used by
POV-Ray is implemented. Does that mean it's *impossible* to replicate the
random number generator in SDL? Of course not.

  Imagine a variant problem: Someone wants to know what is the current
32-bit seed in a RNG stream. There's no interface in SDL to retrieve this
value. Does this mean it's *impossible* in SDL to calculate this value?

  No, it's not impossible.

> >   You have failed completely to explain the problem. You have just rambled
> > about how something is impossible in SDL without giving any actual example.

> In case you don't realize, knowing that a feat is fundamentally impossible *is*
> a valuable contribution to a problem, because it makes clear that it's not
> worth trying.

  Lying is not the correct answer.

  The correct answer is: While it may be theoretically possible to make
the macro calculate the exact result, it's not worth the effort (because
the result will not be significantly, if at all, more accurate than the
current approximation method).

> All you contributed doesn't help the OP in any way. All your claiming that there
> *is* a way without showing *how* is only suited to potentially confuse.

> So, tell us, how can the macro be fixed - or please STFU.

  And exactly what did you contribute? You claimed that it's *impossible*,
which is simply not true.

  Just because something is difficult and impractical and has little value
is not the same thing as *impossible*.

> 'Nuff said, or I'll get real personal. Get out of that "I know better" mode
> you're currently in, Warp.

  Maybe you should look into the mirror sometime?

-- 
                                                          - Warp

Post a reply to this message