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

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