Another sample of your misunderstanding even the OP:

-------- You:
  The original poster asked if it's possible to calculate the direction of
the spline with complete accuracy. You said that it's impossible. That's
clearly not true.
--------

He did not generally ask about calculating the direction of the spline with
complete accuracy. He asked about whether the macro could be improved to do
that, to make it "more elegant".

It *is* impossible to make it more elegant.

Unless we exclude the possibility of modifying the POV-Ray source code, of
course... or writing an SDL parser in SDL, that would read the original code
and extract the spline definition from that source... yeah, I admit that I
forgot about *that* possibility...

Post a reply to this message

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

Warp <war### [at] tagpovrayorg> wrote:
> > 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.

Yes, I was sidetracked by your ranting, and perfectly forgot what my initial
motivation was to assume that passing the whole spline type & control points
was not an option. Looking back at the original posts reminded me.

He talks about rewriting the macro to make it "more-elegant and
'all-inclusive'". I'd never consider a macro to receive the whole spline type
and parameters as distinct parameters (whether discrete or as an array) to fit
that bill - or even come anywhere close.

You can't make the macro "more elegant and 'all-inclusive'" that way - to the
contrary, you'd just clutter it up and make it outright ugly. And a PITA to
use.

Again a fundamental impossibility. Which I took for granted in this case, yes.


> > ------ 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.

I don't really care what it *sounds* like to *you*. Obviously you simply
misunderstood my post there.

The only reference in the OP to "exact alignment" that I posted was this
(emphasis added):

"the code should be rewritten to be more elegant and 'all-inclusive,' so to
speak--SO THAT A VALUE OF ZERO IS EXACT ALIGNMENT"

Why you put so much emphasis on "exact alignment" only and perfectly ignored the
context is far beyond my grasp.


>   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).

Aaaah - now *THAT* sounds much different now. With "IMO shaky" instead of
categorical statements along the lines of "that's a lie", I have no problem
accepting your position.

My attempt was to give a short overview of the problem, with the focus on where
that near-but-not-quite-zero comes from in the first place; I never meant to
write a scientific paper about the issue.

If you find it too shaky - fine; you never were the "target audience" of my post
anyway. I'll leave it up to the OP to decide whether it was helpful or not.


>   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).

.... which, as we have seen, wasn't really my statement, but rather what you
misunderstood it for. And you took a long time to figure that out.

> > 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.

.... and perfectly "un-elegant", thereby missing one of the OP's main goals.

Post a reply to this message

I've been waiting for the smoke to clear on the battlefield... :-P

"clipka" <nomail@nomail> wrote:

> 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.

Yes, completely understood. (It's been ...*awhile*...since I took a calculus
course, and I'm certainly NO expert.) I guess, in the context of the math
discussions here, what I'm looking for IS finding the 'limit' at
delta-*something* = 0. But I see the difficulties (I think!)
>
> 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.

That piques my curiosity. I thought calculus was the 'prime tool' for getting
that exact tangent. So, do I understand that POV-Ray can't actually calculate
that?  (Sorry if my ignornace is showing.)

But more prosaically, my original question--a rather naive one, as I see
now--was really about the *idea* of being able to set Foresight to zero. As a
way for the macro to 'make better sense' to the user. Of course, I do now see
the practical difficulties involved.  (Here's a REALLY goofball idea: Maybe,
'behind the scenes' in the macro, there could be a little 'hidden' addition of
..001 or something, so that when Foresight IS set to zero, the equations will
still have a little number to work with.)  Silly, I know. Even stupid! :-O  And
not even good coding practice, I would assume.

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> I've been waiting for the smoke to clear on the battlefield... :-P

Hm, I think it has cleared now... mainly :}

> Yes, completely understood. (It's been ...*awhile*...since I took a calculus
> course, and I'm certainly NO expert.) I guess, in the context of the math
> discussions here, what I'm looking for IS finding the 'limit' at
> delta-*something* = 0. But I see the difficulties (I think!)
> >
> > 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.
>
> That piques my curiosity. I thought calculus was the 'prime tool' for getting
> that exact tangent. So, do I understand that POV-Ray can't actually calculate
> that?  (Sorry if my ignornace is showing.)

It could - as Warp has pointed out quite correctly - if someone programmed it
with the correct precise formula.

The catch here, however, is that this would also require feeding that formula
with all the control point parameters that normally go into the spline
definition already. Unfortunately it's not possible to access that information
via SDL from an arbitrary spline, so you'd have to remember this information
and "manually" feed it into a suitable macro (or function, for that matter).

> But more prosaically, my original question--a rather naive one, as I see
> now--was really about the *idea* of being able to set Foresight to zero. As a
> way for the macro to 'make better sense' to the user. Of course, I do now see
> the practical difficulties involved.  (Here's a REALLY goofball idea: Maybe,
> 'behind the scenes' in the macro, there could be a little 'hidden' addition of
> ..001 or something, so that when Foresight IS set to zero, the equations will
> still have a little number to work with.)  Silly, I know. Even stupid! :-O  And
> not even good coding practice, I would assume.

Indeed, it would deprive the user of choosing for himself how close to zero to
go.

So if you want to go for a "standard almost-zero", the proper way would be to
write a similar macro without that parameter, which would then use a fixed
value.

However, I can also imagine that such a "tweaking screw" can come in handy
occasionally when the results are a bit weird. Maybe some spline taking an
unconventionally sharp turn. It can also serve to smoothen out the transitions
in linear splines a bit, by deliberately setting it somewhat larger than zero.

So all in all, I think the parameter is there for good - provided that you heed
the advice to choose a value not *exactly* zero ;)

Post a reply to this message

> "Kenneth" <kdw### [at] earthlinknet> wrote:
>
> > But more prosaically, my original question--a rather naive one, as I see
> > now--was really about the *idea* of being able to set Foresight to zero. As
> > a way for the macro to 'make better sense' to the user. Of course, I do now
> > see the practical difficulties involved.  (Here's a REALLY goofball idea:
> > Maybe, 'behind the scenes' in the macro, there could be a little 'hidden'
> > addition of .001 or something, so that when Foresight IS set to zero, the
> > equations will still have a little number to work with.) A silly idea...


"clipka" <nomail@nomail> wrote:
> Indeed, it would deprive the user of choosing for himself how close to zero to
> go.
>

And Warp wrote (taken out of context)...
> Two points on the spline gives you an approximation of the direction of
> the spline (which is what is used here). The closer the points are to each
> other, the more accurate the direction will be. Of course one could hastily
> think that you should then use something like 1e-100 as the distance between
> the two points to get a very very very accurate direction. However, the
> drawback of using two points which are too close to each other is that you
> start losing accuracy (due to the limited size of floating point numbers).
> Thus using a distance of 1e-100 is not a good idea, as you will most probably
> get a larger error than with eg. a distance of 1e-10.

That's the only 'real' trouble with the macro (actually more of a mystery than a
problem): how small to make Foresight to get 'bleeding edge' alignment accuracy,
without going so low as to cause the equations to flip the object 90-deg. (I
haven't yet done any tests to see what that value might be.) No mention of it
in the docs, unfortunately. I'm sure there's *some* kind of formula for
determining that--probably based on the 'limited size of floating point
numbers.' But in a practical sense--from the user's standpoint--it would be
useful if the docs actually stated such a lower-limit value, whatever it is.
That would keep any 'surprises' at bay. (Or--egads!--does the value depend on
other parameters like spline type?)

KW

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> That's the only 'real' trouble with the macro (actually more of a mystery than a
> problem): how small to make Foresight to get 'bleeding edge' alignment accuracy,
> without going so low as to cause the equations to flip the object 90-deg.

  You have to consider that after a certain accuracy has been achieved
(by making the distance between the two sample points close enough),
increasing the accuracy even further will have such a small effect that
it will disappear in all the other calculations being made afterwards
(eg. to rotate an object or whatever). Or put in other words: If the
direction is already accurate eg. to the 15th decimal, getting the 16th
decimal correct might be useless because subsequent calculations may have
rounding errors larger than that.

  Also if you think about it in practice, if you use the direction to eg.
reorient an object, after a certain accuracy any further accuracy would
transform the object so little that it will be like a millionth of a pixel
in the final image. The extra accuracy will be lost when actually rendering
the final image (if for nothing else, because pixels use only 8 or at most
16 bits per channel, and any accuracy change beyond a certain point will
be completely lost in the final image).

-- 
                                                          - Warp

Post a reply to this message

> That's the only 'real' trouble with the macro (actually more of a mystery 
> than a
> problem): how small to make Foresight to get 'bleeding edge' alignment 
> accuracy,
> without going so low as to cause the equations to flip the object 90-deg. 
> (I
> haven't yet done any tests to see what that value might be.) No mention of 
> it
> in the docs, unfortunately. I'm sure there's *some* kind of formula for
> determining that--probably based on the 'limited size of floating point
> numbers.' But in a practical sense--from the user's standpoint--it would 
> be
> useful if the docs actually stated such a lower-limit value, whatever it 
> is.
> That would keep any 'surprises' at bay. (Or--egads!--does the value depend 
> on
> other parameters like spline type?)

As Warp pointed out, going to really small values isn't really worth it most 
of the time.

As a rough rule-of-thumb, if R is the minimum radius of curvature in your 
spline, and D is the minimum error acceptable (in degrees) between the 
actual direction and the calculated direction, then use a foresight length F 
of:

F = R * D / 50

For example, if the tightest part of your spline is similar to a circular 
arc of radius 5 units, and you want alignment accuracy to within 1 degree, 
then use a foresight length of 5 * 1 / 50 = 0.1 units.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

>   You have to consider that after a certain accuracy has been achieved
> (by making the distance between the two sample points close enough),
> increasing the accuracy even further will have such a small effect that
> it will disappear in all the other calculations being made afterwards
> (eg. to rotate an object or whatever)...
>
>   Also if you think about it in practice, if you use the direction to eg.
> reorient an object, after a certain accuracy any further accuracy would
> transform the object so little that it will be like a millionth of a pixel
> in the final image.
>

Yeah, I have to agree--'bleeding edge' accuracy really isn't necessary, from a
practical standpoint.

Yet, from the user's standpoint, the docs still leave out a few details that
would be useful (to avoid 'mysterious behavior'): What exactly *is* meant by a
'low' value for Foresight; and what's the lowest value that we shouldn't go
below. In light of all that's been said, I think the only thing that *is*
needed is a caveat in the docs--perhaps in one of those yellow boxes--something
like this:
"Since it's mathematically difficult to determine EXACT alignment using
Foresight, a recommended lowest value is *-----*."

Not the LOWEST bleeding-edge value, but one that allows some headroom, to avoid
*any* object-flipping. Just an empirically-derived value. That would be enough
to avoid problems, IMO.

KW

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:

>
> As a rough rule-of-thumb, if R is the minimum radius of curvature in your
> spline, and D is the minimum error acceptable (in degrees) between the
> actual direction and the calculated direction, then use a foresight length F
> of:
>
> F = R * D / 50
>
> For example, if the tightest part of your spline is similar to a circular
> arc of radius 5 units, and you want alignment accuracy to within 1 degree,
> then use a foresight length of 5 * 1 / 50 = 0.1 units.

I think *this* would make a good addition to the docs as well! Although it's a
bit technical, there are similar kinds of 'detailed explanations' to be found
in other parts of the docs, for those who want/need them. (And in fact, the
idea that Foresight is actually a 'length' and vector direction--between two
adjacent, interpolated spline points--would be good to advertise too.)

KW

Post a reply to this message