clipka <nomail@nomail> wrote:
> ------ OP:
> > How these things may affect the Matrix, Transform and VProject_Plane stuff there
> > is beyond me; but Foresight=0 obviously isn't a good recipe for success.
> > IMHO--and in an ideal world-- the code should be rewritten to be more elegant
> > and 'all-inclusive,' so to speak--so that a value of zero IS exact alignment.
> ------

> Now here we have a request to make the macro "more elegant and 'all-inclusive'"
> - does that sound like the OP desires to impose *additional* requirements on
> the caller, like telling the macro what type of spline it is to be dealing
> with?

  He talks about rewriting the code but makes no mention about preserving
the interface to the macro.

> ------ Me:
> It's fundamentally impossible to do that.
> ------

> This is me referring to the task of making the macro work for the value of zero

  It sounds more like you were saying that achieving "exact alignment"
is fundamentally impossible.

  (On a side note, that interpretation would actually be technically correct
too, because floating point arithmetics have limited accuracy, and thus
getting *exact* results is not possible except for very few exceptional
cases. However, you were not talking about floating point accuracy at this
point.)

> (or rewriting the macro in any other way that would make it more elegant).

  I didn't see anything like that in your original post.

> ------ Me:
> Are you familiar with calculus?

> Exact alignment would mean that the current direction would be the tangent to
> the spline at the current position.

> To compute a tangent to an arbitrary curve defined as f(t) (the value of which
> in this case is a vector), you need the derivative f'(t) of that function,
> which is defined as:

>     f'(t) = lim(d->0) [f(t+d)-f(t)]/d

> which is to say, take two *infinitesimally* close points on the function, and
> divide the difference between the function values by the difference between the
> function parameters.

> As you will see, although this is an exact mathematical definition, it doesn't
> work with d = 0 because you'd get 0/0, which is nonsense.
> ------

> Now, here I do a - very small - excursion about the relationship between a
> spline tangent, a spline function, and a derivative - and how that
> "near-but-not-quite-zero" parameter comes to be.

> Tell me, is there anything in there that is wrong?

  Your explanation is a bit shaky, IMO. You are argumenting why calculating
a derivative is impossible because all you get is a 0/0 (because the points
are infinitesimally close to each other).

  Maybe what you meant was the same as what I replied to the OP. In other
words, since the approximation takes two points on the spline and calculates
the direction vector from them, taking the two points from the exact same
location on the spline cannot give any result because it's basically a
division by zero. However, your explanation of this is rather contrived.

> ------ Me:
> Of course even POV-SDL macros cannot overcome fundamental mathematical
> limitations.
> ------

> Do you disagree on this point?

  I was not disagreeing with the point that a vector of zero length has
no direction (which is what I wrote in my reply to the OP as well). I was
disagreeing with your statement that getting a completely accurate result
is essentially impossible (sans the inaccuracies of floating point).

> ------ Me:
> The only alternative would be to figure out a general formula for f'(t) for the
> spline type and parameters in question - but as there is no way to query either
> of these from SDL, we're stuck with what the macro does.
> ------

> Here I explicitly *do* mention the option of figuring out a general formula for
> f'(t).

  Which is why I considered your statements contradictory in the first place:
It *is* possible to get the accurate result, using the partial derivative
functions. (*How* you get those derivatives is another story, but it's
perfectly possible.)

> I also mention the core problem of "making the macro more elegant": The
> impossibility to query an existing spline's type and parameters from SDL.

> Note that it's not sufficient to know the *type* of a spline - you also need to
> know *all* its control points.

> You want to make a macro more elegant by forcing the user to re-supply *all* the
> values he has already placed in the spline definition?

  As I said many times, it would be impractical, but perfectly possible.

-- 
                                                          - Warp

Post a reply to this message