Posting here in a new thread since advanced users does not support attachments.
:|


Maybe I'm a bit daft here, but can you please elaborate on the above
notation? Does each line represent something you tried inserting...
somehwere?

Yes.

After the `#for()` statement?... with the left showing the
result and the right showing the statement you tried?

Yes.

Did you try each
of the lines individually, or did you add them one after the other in
the above order?

I had added them all, to see why you somehow were able to have the comparison
evaluate successfully, and have the code execute without error, and then I
commented out two of them and cycled through, thus narrowing the problem down to
why #local U = 0; "fixes" the issue.

Does "no effect" mean you didn't get the desired
effect, or does it mean the observed effect isn't there? Does "Code
proceeds" mean the code works, or does it mean the `#if` clause is skipped?

No effect means I get the existing error, where the comparison craps out and the
loops runs out until I get the uninitialized array element error.


Hunting down obscure bugs is a matter of precision. This seems to be
something so strange that I need to understand /exactly/ what you're
doing and /exactly/ what your results are.

Yes, I would agree.
This happens in 3.7.0.msvc10.win64, Mr. Balaska's current QTPOV-Ray version,
(both on the same laptop, dual-boot) and the (IIRC) 32-bit 3.7.0 version on the
tower at work.


This is all the more important since I still don't seem to get the same
results; so either I didn't fully understand your description to allow
me to reproduce it - in which case precision is important so that I can
figure out what I'm still doing differently than you - or thre is
something fundamentally different between my environment and yours - in
which case precision is important because your description of the
scenario is all I have to go by to understand the root cause.

Yes.   I'm hoping it's just some strange thing that I'm reading through and not
catching

> So I tried #local U = int (U);   Nope.

You tried that where? And what exactly does "Nope" mean?

Immediately after the #for (U, 0, Usize) statement, with all of the other three
#local statement commented out.

> So, #for (U, 0, .... doesn't actually start at 0???   :|

I can pretty much rule that one out: The parser takes the literal `0`
and immediately assigns it to the local variable U, with no other fancy
operations involved. If there are any two statements by which you can
absolutely positively reliably get a clean genuine zero into some
variable, it is `#declare/local Foo=0;` and `#for (Foo,0,...)`.

Yes, I had both assumed and hoped that was the case, which makes this latest
SNAFU/FUBAR all the more puzzling.

Attached are scene, includes, and a developmental model of the function for the
CURVE section at the end of the main scene file.

Post a reply to this message

Attachments:
Download 'scenefiles.zip' (11 KB)

Am 16.09.2018 um 02:36 schrieb Bald Eagle:

> I had added them all, to see why you somehow were able to have the comparison
> evaluate successfully, and have the code execute without error, and then I
> commented out two of them and cycled through, thus narrowing the problem down to
> why #local U = 0; "fixes" the issue.

Huh? I thought the problem was that some variation of "0*N <= 0" didn't
seem to work out; now you're saying that "U=0" wasn't holding?

But the output you posted from the `#debug concat ("Testing Y = ...`
statement clearly showed that at least the debug output accessed the
expected element of UArray, so why should the subsequent `#if` statement
access a different element of UArray, if they both access element [U]?


> This happens in 3.7.0.msvc10.win64, Mr. Balaska's current QTPOV-Ray version,
> (both on the same laptop, dual-boot) and the (IIRC) 32-bit 3.7.0 version on the
> tower at work.

I presume that comma after "3.7.0.msvc10.win64" stands for "and", not
further qualification; i.e. it happens in official POV-Ray for Windows
as well as in QtPOV-Ray.

That pretty much rules out the tenth level of floating point hell
hypothesis, because the official POV-Ray for Windows binaries use
"proper" floating point math.

It also means that we both /should/ get exactly the same results,
because official version 3.7.0.msvc10.win64 is precisely the versions
I've just verified my results with the code you posted prior to posting
my most recent replies.

So the `#if` clause MUST be entered in the first loop iteration (which
/should/ be, and /is/, U=0, with UArray[U]=<0,0,1.047something) -
because that's what is to be expected, and that's what I am absolutely
positively seeing here, double-checked and all, with the exact same
piece of software - unless your CPU is buggy, or some gremlin has pooped
on your RAM, or whatever.


> Attached are scene, includes, and a developmental model of the function for the
> CURVE section at the end of the main scene file.

Sounds like not a minimal scene.
Is it any more enlightening than the code you posted earlier?

Post a reply to this message

....  thus narrowing the problem down to
> > why #local U = 0; "fixes" the issue.
>
> Huh? I thought the problem was that some variation of "0*N <= 0" didn't
> seem to work out; now you're saying that "U=0" wasn't holding?

Debugging developments, my Dear Boy.  The Game is afoot!

> But the output you posted from the `#debug concat ("Testing Y = ...`
> statement clearly showed that at least the debug output accessed the
> expected element of UArray, so why should the subsequent `#if` statement
> access a different element of UArray, if they both access element [U]?

Yeah - no kidding.  I have tried my best to pore over this, and am gonna go
blind or insane - which is usually the point at which I ask for genuine help.

At Line 318, I even threw in:
#if (U = 0) #debug "U = ZERO \n" #end


> > This happens in 3.7.0.msvc10.win64, Mr. Balaska's current QTPOV-Ray version,
> > (both on the same laptop, dual-boot) and the (IIRC) 32-bit 3.7.0 version on the
> > tower at work.
>
> I presume that comma after "3.7.0.msvc10.win64" stands for "and", not
> further qualification; i.e. it happens in official POV-Ray for Windows
> as well as in QtPOV-Ray.

Correct - one runs on the win partition, and the other runs on the Mint
partition of the exact same laptop.

> That pretty much rules out the tenth level of floating point hell
> hypothesis, because the official POV-Ray for Windows binaries use
> "proper" floating point math.

Which is why I switched over to Windows, to see if there was an issue with
running it on the QTPOV-Ray build.

> It also means that we both /should/ get exactly the same results,
> because official version 3.7.0.msvc10.win64 is precisely the versions
> I've just verified my results with the code you posted prior to posting
> my most recent replies.


> So the `#if` clause MUST be entered in the first loop iteration (which
> /should/ be, and /is/, U=0, with UArray[U]=<0,0,1.047something) -
> because that's what is to be expected, and that's what I am absolutely
> positively seeing here, double-checked and all, with the exact same
> piece of software - unless your CPU is buggy, or some gremlin has pooped
> on your RAM, or whatever.

I think I'm reading that correctly.
You are now as officially perplexed as I am.
{But perhaps a ram has pooped on my Gremlin - and then I'd need a car wash.}

> Sounds like not a minimal scene.

It's the whole "closed system", to give you the most "precise" (accurate) way to
replicate what I'm seeing over here.  Now we can reference exact decimal line
numbers and everything.  The code you're working with "should be" good enough
.....  and that exact code (minus line break artefacts) was what I ran on my work
machine before copy-pasting it, so ....

> Is it any more enlightening than the code you posted earlier?

It "shouldn't be" - but precise is precise.  Running the scene in the zip with
the includes leaves no room for "that's not the exact code you posted..." and so
there shouldn't be ANY ambiguity, and you can tell me if the values I'm looking
at - out to 32 decimal places - are off, or I'm using one wrong variable name,
or syntax, or ---- something else I'm completely "familiarity-blind" to at this
point.

(I know, I know - the upper limit for that range (as shown below) is now
0.89759790102565518 - where it ought to be, but I'm not testing against the
upper limit now, am I?)

_X = 0.00000, _Y = 0.00000
Starting macro PatchUV
Starting macro ThisPatch
U = ZERO
Testing YVal = 0.00000000 vs
 [U=0.00000000] <0.00000000000000000000000000000000,
0.00000000000000000000000000000000, 0.89759790102565518000000000000000>





I mean, I'd love to get this worked out, and understand what the problem is -
but I'm getting that "He's gonna KILL me when he finally finds ..... whatever
stupid thing is wrong" feeling.  :(

But I mean, paste
#local U = 0;
into there and watch it go...
It'll loop endlessly, obviously.... but it doesn't step up to a U value
referencing an uninitialized array element either.

I'll play with some flags and also try converting it to a
#while (U < Usize)
loop tomorrow....




(I can only imagine the insanity that must occur on projects with tens of
thousands or millions of lines of code....)


If you haven't completely oriented yourself to the flow yet,
around Line 662 starts a new section of code that just "adds onto" the scene
generated by the prior code.
Loop from 0 to 1
Calculate x and y values (u and v) and pass those to the PatchUV macro at Line
361.   That calls ThisPatch macro which gives the array element corresponding to
an individual bicubic_patch, and then the rest of the PatchUV macro is supposed
to locate exactly where on that bicubic patch the point lies.

I was working on getting PatchUV to give me the desired and expected final scene
results when the current issue popped up.

Post a reply to this message

Am 16.09.2018 um 05:09 schrieb Bald Eagle:

>> Sounds like not a minimal scene.
> 
> It's the whole "closed system", to give you the most "precise" (accurate) way to
> replicate what I'm seeing over here.  Now we can reference exact decimal line
> numbers and everything.  The code you're working with "should be" good enough
> ......  and that exact code (minus line break artefacts) was what I ran on my work
> machine before copy-pasting it, so ....

Aaaaaalright, I'll give it a shot.

You wouldn't mind telling me which of the three `.pov` files is the one,
would you?

Post a reply to this message

Am 16.09.2018 um 14:33 schrieb clipka:
> Am 16.09.2018 um 05:09 schrieb Bald Eagle:
> 
>>> Sounds like not a minimal scene.
>>
>> It's the whole "closed system", to give you the most "precise" (accurate) way to
>> replicate what I'm seeing over here.  Now we can reference exact decimal line
>> numbers and everything.  The code you're working with "should be" good enough
>> ......  and that exact code (minus line break artefacts) was what I ran on my work
>> machine before copy-pasting it, so ....
> 
> Aaaaaalright, I'll give it a shot.
> 
> You wouldn't mind telling me which of the three `.pov` files is the one,
> would you?

Well, I guess it can't be `BillsArrayMacros.pov`, because that one
complains with an `#error` directive when attempting to parse it directly.

`BezierStitching_Test_3.pov` gives me a `Cannot find file
'GridMacro.png' in line 91, which I /think/ is not the problem we're
talking about.

`Equation_UVMap.pov` runs without an obvious hitch, nor any debug
output, and from a first glance I would say the rendered scene may make
sense, too.


So, what am I looking for?

Post a reply to this message

Am 16.09.2018 um 14:46 schrieb clipka:

> `BezierStitching_Test_3.pov` gives me a `Cannot find file
> 'GridMacro.png' in line 91, which I /think/ is not the problem we're
> talking about.

Okay, now that I've just bypassed that offending image_map and bump_map,
I get an error in line 324, the `#debug` line printing `Testing YVal =
...`, at what appears to be index U=7.


If I place a `#debug "***MATCH!***\n"` in line 327 in front of the
commented-out `#if` statement, I get the following output:

------------------------------------------------------------------
[...]
_X = 0.00000, _Y = 0.00000
Starting macro PatchUV
Starting macro ThisPatch
U = ZERO
Testing YVal = 0.00000000 vs
 [U=0.00000000] <0.00000000000000000000000000000000,
0.00000000000000000000000000000000, 0.89759790102565518000000000000000>

***MATCH!***
Testing YVal = 0.00000000 vs
 [U=1.00000000] <1.00000000000000000000000000000000,
0.89759790102565518000000000000000, 1.79519580205131040000000000000000>

Testing YVal = 0.00000000 vs
 [U=2.00000000] <2.00000000000000000000000000000000,
1.79519580205131040000000000000000, 2.69279370307696550000000000000000>
[...]
------------------------------------------------------------------

Note how this clearly and unambiguously demonstrates that the `#if`
condition in line 326 is met in the first loop iteration, i.e. POV-Ray
properly recognizes that YVal = 0 falls neatly inside the range
[0...whatever), and is consistent with it properly examining array
element 0, not anything else.


So my current hypothesis is that you /think/ the error at U=7 is not the
one you're looking for, but it's the one you're actually fighting with
at the moment.

This is also perfectly consistent with your observation that a `#local U
= 0;` right at the beginning of the loop "fixes" this issue, because
then the loop is stuck at U=0 and never reaches the offending index U=7.


Now if I weed out the cruft that's in the way - the one you say you
hoped to fix later - and change the `#for` loops in lines 316 and 337,
to run not to `Usize` and `Vsize` respectively, but `Usize-1` and
`Vsize-1`, this part of the code starts to run smoothly...


... and, hey presto! *NOW* I can at last witness the "Attempt to access
uninitialized array element" error you're presumably /really/ trying to
solve. /Now/ that /I/ have weeded out the cruft (as I had earlier
suggested /you/ do), I can at last get down to the bottom of it, rather
than fight with you about ghosts you're seeing that I'm not seeing.

And I find that while you've been trying to debug the "U side" of the
macro, the actual error message pertains to array elements initialized
by the "V side" of the macro; and indeed, there's a neat little debug
message:

    _Patch [3] V not defined

which confirms that the V side has failed to kick in, not the U side.

And if I look closely at the case at hand, I see why: The error happens
at _X (which goes into the V side) = 6.300; the ranges in VArray[] only
go up to ~6.283 though, so no matching range is found. Now theoretically
the problem might be that VArray is too short, and should be initialized
longer; but since the upper bound of the last tested array element is
equal to 2*pi, it seems plausible that VArray is fine, so _X must be at
fault.

Now all we have to figure out is why _X goes beyond 2*pi in the first
place, and we have the whole case solved.

Or you have to make _X wrap around to the range [0..2*pi) if it goes out
of that range.


I leave the rest as an exercise to you. Let me know if you hit another
impasse.


Isn't it fascinating how quickly one can get to the bottom of a problem
once a little bit of cruft, which you /thought/ was insignificant but
totally obstructed my view on things and skewed yours, has been moved
out of the way?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Isn't it fascinating how quickly one can get to the bottom of a problem
> once a little bit of cruft, which you /thought/ was insignificant but
> totally obstructed my view on things and skewed yours, has been moved
> out of the way?

Yes, which is I why I solicited your help, because you'd think (and do) things I
wasn't doing.

Lots of little things in there that serve as a tutorial for debugging.


Your help and expertise is very much appreciated, as always.

Sometimes you just get stranded at the side of the road and need someone to
drive up with jumper cables.   (thumbs up)

Thanks!

Post a reply to this message