"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> The other thing that helps to work this all out in your head is to not delete
> code that doesn't work.   Otherwise you wind up coding the same mistakes over
> and over again.

Absolutely! My current real scene code is full of commented-out sections that
failed, along with notes as to why (well, at least at my current level of
understanding, ha.) Unfortunately, much of my 'knowledge' is currently spread
through hundreds of my previous files, so I have to think hard as to *where* I
might have put a particularly useful note.

Your own method of adding accumulated tidbits of knowledge into a spreadsheet--
like a 'library' of known facts-- is the envy of the modern world. ;-)  Alas, I
have not gotten around to implementing that major 'tuit.
>
> Do a #switch #case #break #end block, and copy-paste #case 1 into #case 2 and
> then edit case 2.  If that fails, work on case 3.   That way you have
> a running documentation of what you've tried, what the results look like,
> notes on why it failed, what worked, etc... What doesn't work is often more
> important to know than what does.

Exactly, Northern Cousin Walker. Excellent advice.

> If you have A which needs X, and B which needs Y, and C which needs Z,
> and D which needs W, then if you have A(B(C(D()))), your function A needs:  A
> (X, Y, Z, W) {}, and so on, as you go further down into the curly braces.

This is the concept that I have the most trouble understanding...although I'm
making slow progress.

My apologies for going a bit off-topic here, but I was recently going through
someone else's old code that uses this idea brilliantly-- it's very complex,
with nested functions-- and I *think* I came across a particular section that I
don't fully understand.

Using your example: When A(X,Y,Z,W){} is the major function, I would imagine
that *all* of these variables (arguments?) in the body of the function would, at
some point in the code, have to be replaced with some actual value or other
pre-#declared variable. In almost all of the instances of X,Y,Z and W, that is
so. But in one section, there appears to be just W-- used as-is and not with any
substitution. (Sorry if I'm not describing this understandably.) AFAICT, there
is nowhere in the entire scene code that has *something* pre-declared for W. So
in this case, what does that 'naked' W represent? The code *works* of course--
and I've tried substituting actual float values for that one mysterious instance
of W, in my usual fumbling trial-and-error way...but with always-fatal results.

If indeed that one W is 'naked' so to speak, and I haven't made a stupid error
in detecting a substitution for it, then how does it work successfully? If I
could figure *that* out, it would certainly expand my understanding of POV-ray's
function use.

Post a reply to this message