clipka <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   I don't have the motivation to study exactly which mathematical function
> > POV-Ray is using for its splines nor calculating its derivatives.

> You do have the motivation throwing smart statements about, but you don't have
> any motivation to really investigate the issues you are talking about.

> Wise guy.

  Then you, as a wiser person than me, could explain to me why it would be
impossible to calculate the tangent of a spline using its derivative
functions. I'm so stupid that I can't understand why it's impossible.

> You don't have to calculate any particular spline's derivative to find out what
> the problem is. You just have to look at the macros and SDL statements we're
> discussing about, to find out that you're overlooking a much more serious
> obstacle.

  What obstacle?

  The question was: Is it possible to calculate the tangent of a spline with
absolute accuracy? The answer is obviously: Yes, it's possible.

  What does the macro you are talking about have anything to do with this?

> >   I don't see the problem you are having. A derivative function is nothing
> > more than a function. In the exact same way as you can create a macro which
> > returns values of a function, you can create another macro which returns
> > values of its derivative function. Because it's just another function.

> BTW, *I* am not having *any* problem. I'm just describing why a problem the OP
> has is inevitable.

  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.

> Anyway, we are talking about macros. SDL statements, you know?

  So what? What is it in SDL that prevents you from evaluating a function?

> So how do you get the function value of an arbitrary spline out of POV-Ray?

  Splines are not "arbitrary". They have a well-defined formula.

> Rrrright - you use an interface built into the SDL, which lets you use the
> spline as a function.

> Fine. Now how do you get the derivative value of an arbitrary spline out of
> POV-Ray?

  Maybe you should go back to school to learn how to calculate derivatives
because you clearly don't seem to grasp the concept.

> Mind you: The spline type and coefficients are buried in the bowels of POV-Ray.

  So what? Does that mean you cannot calculate its derivative? It's not
like POV-Ray would be proprietary closed source.

> If you want to get at them from SDL, you need an interface to do that.

  Why can't you just write the functions in SDL? Is there something in
there that cannot be done in SDL?

> No
> interface - no access to the data. No access to the data - no way to insert the
> data into your derivative formula (let alone decide on which formula to use,
> because we don't even know the type of the spline).

  You are seriously claiming that it's impossible to write a spline function
in SDL? Maybe you should check eg. Colefax's spline includes.

  There's no basic difference between Colefax's spline includes and the
internal splines used in povray, except maybe for some coefficients.

> Now, your turn. Stop blurping and show what you *really* know and understand
> about the OP's question.

> And no excuses: If you're too lazy to really investigate a certain matter,
> better hold your breath about it right from the start.

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

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   What obstacle?
>
>   The question was: Is it possible to calculate the tangent of a spline with
> absolute accuracy? The answer is obviously: Yes, it's possible.
>
>   What does the macro you are talking about have anything to do with this?

....

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

*Sigh*

RTFOP, man. If you did, then please do so again.

The OP was all about "fixing" that *macro*.

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


>   So what? What is it in SDL that prevents you from evaluating a function?
....
>   Maybe you should go back to school to learn how to calculate derivatives
> because you clearly don't seem to grasp the concept.

This is getting ridiculous. Read my posts. Again if you like. Until you have
grasped it.

Or leave it if you're too lazy or stoned or whatever.

I'll try just once more again:


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

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

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

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


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

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.


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

Post a reply to this message

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

Warp <war### [at] tagpovrayorg> wrote:
>   The macro can be told by the user what type of spline it is.
> Practical? No. Impossible? No.

The macro to "fix" currently accepts a generic spline. Changing that would break
any scene currently using the macro (let alone any framework designed to handle
arbitrary spline types and using this macro), and is therefore *NOT* an option
I consider anywhere close to valid.


>   Lying is not the correct answer.

Man, I don't have to take this from you! What did you smoke this morning??

Post a reply to this message

clipka <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   The macro can be told by the user what type of spline it is.
> > Practical? No. Impossible? No.

> The macro to "fix" currently accepts a generic spline. Changing that would break
> any scene currently using the macro (let alone any framework designed to handle
> arbitrary spline types and using this macro), and is therefore *NOT* an option
> I consider anywhere close to valid.

  That's not what you said in your original post. You made absolutely no
mention of "it's impossible to do without modifying the amount of parameters
taken by the macro". You just said it was impossible because of some
derivative which would have to be calculated. Your arguments were incorrect.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   That's not what you said in your original post. You made absolutely no
> mention of "it's impossible to do without modifying the amount of parameters
> taken by the macro". You just said it was impossible because of some
> derivative which would have to be calculated. Your arguments were incorrect.

No, they were not. They were just based on assumptions that you failed to grasp.
So you've been trying hard to troll your way out (and still are), trying not to
lose your face about it.

Admit it: You understood bullshit, so you wrote bullshit. Happens to the best of
us.

It has always been about a library macro. Changing interfaces of library macros
that must be expected to be in widespread use is never an option. My mistake,
admittedly, was probably in assuming that you were aware of this.

That mistake doesn't change a iota of the fact that with the given interface,
fixing the macro is impossible. Fundamentally.

And calling me a *liar* - mind you, that's a word usually reserved for people
*deliberately* telling nonsense - is *way* over the top. It would be even if I
had been mistaken.

Post a reply to this message

clipka <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   That's not what you said in your original post. You made absolutely no
> > mention of "it's impossible to do without modifying the amount of parameters
> > taken by the macro". You just said it was impossible because of some
> > derivative which would have to be calculated. Your arguments were incorrect.

> No, they were not. They were just based on assumptions that you failed to grasp.
> So you've been trying hard to troll your way out (and still are), trying not to
> lose your face about it.

> Admit it: You understood bullshit, so you wrote bullshit. Happens to the best of
> us.

  You are being ridiculous. Maybe you should reread what I wrote and what
you wrote?

  You never mentioned a single word about it being impossible given the
requirement that the library interface must not be changed. You only talked
about calculating derivatives and that it must be done "in SDL" (you still
didn't specify anything about macro parameters, only "in SDL"). I wasn't
talking about preserving any macro parameters either. Only in your last
post did you mention anything at all about this arbitrary requirement.

  But hidden inside all your ranting is an indirect admission that it indeed
*is* possible to calculate the tangent of the spline accurately using SDL.
You have just now changed your claim from a generic "impossible" to a more
specific "impossible without changing the macro calling parameters".

  So you might not admit it directly, but you are conceding that I was not
mistaken.

> It has always been about a library macro. Changing interfaces of library macros
> that must be expected to be in widespread use is never an option.

  Now it's you who is sidetracking with bullshit. You never mentioned a
single word about interface changes being the main obstacle. You are only
coming up with that stuff now.

  Besides, the very claim "changing interfaces is never an option" is
bullshit in itself, but unrelated to this.

> My mistake,
> admittedly, was probably in assuming that you were aware of this.

  Aware of what? That you were talking about not changing the macro
interface from the very beginning? Even if that's the honest truth,
you certainly didn't mention anything about it.

> That mistake doesn't change a iota of the fact that with the given interface,
> fixing the macro is impossible. Fundamentally.

  You should have said that in your first post.

> And calling me a *liar* - mind you, that's a word usually reserved for people
> *deliberately* telling nonsense - is *way* over the top. It would be even if I
> had been mistaken.

  I didn't call you a liar. Reread that post of mine again, with thought.

  Besides, it was you who started sarcastic namecalling, not me.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   I didn't call you a liar. Reread that post of mine again, with thought.

Nitpicking again.

You wrote "Lying is not the correct answer." - implying that my answer was a lie
and thus me a liar.

Post a reply to this message

So let's analyze what I *really* wrote in my first posting - not what you like
to read from it:

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

------ 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
(or rewriting the macro in any other way that would make it more elegant).

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

Now that a symbolic solution for the derivatives of many functions can be found
is a totally different story: The *definition* is the above.

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

Do you disagree on this 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).

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?


That's it, end of that first post of mine.

So: Where was I wrong in this posting? Or where did I miss the OP's intentions?

Post a reply to this message

.... and here we have your first reply to my posting:

----- You:
clipka <nomail@nomail> wrote:
> It's fundamentally impossible to do that.

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

  I find those two sentences contradictory. First you say that it's
impossible, and immediately after you tell how it's done.

--
                                                          - Warp
-----

You already misunderstood my posting at this point, and never made an attempt to
change that. Things went from bad to worse from here on.

Post a reply to this message