 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I broke POV-Ray.
AGAIN.
Stephen, I'm pouring Scotch in my coffee... :|
#version 3.7;
global_settings {assumed_gamma 1.0}
#declare U1 = 0;
#declare U2 = tau;
#declare V1 = 0;
#declare V2 = tau;
#declare Phi_inc = (tau/360)*30;
#declare Theta_inc = (tau/360)*10;
#declare Usize = (U2-U1)/Phi_inc;
#declare Vsize = (V2-V1)/Theta_inc;
// Run this as-is, and U goes to 11, and V goes to 35
// NOW
// change The line below to Usize+1, and U goes to 11, and V goes to 36 !!! :O
// How can a variable NOT USED in defining the range of a #for loop change the
behaviour of the loop!
// In BOTH variables!
// Usize is never redefined! W T H
#declare StitchedArray = array[Usize+2][Vsize+1]; // <----- Try it!
#for (U, 0, Usize-1)
#for (V, 0, Vsize-1)
#local StitchedArray [U][V] = array[4][4];
#end
#end
#declare PatchArray = array [4][4];
#for (Phi, U1, U2, Phi_inc) // 0 to 2pi
#local U = ceil(Phi/Phi_inc);
#for (Theta, V1, V2, Theta_inc)
#local V = ceil(Theta/Theta_inc);
#local PatchArray[0][0] = 0;
#local PatchArray[0][3] = 0;
#local PatchArray[3][0] = 0;
#local PatchArray[3][3] = 0;
#debug concat ("U1 = ", str(U, 0, 3), ", V1 = ", str(V, 0, 3), "\n")
#declare StitchedArray [U][V] = PatchArray;
#end
#end
#for (U, 0, Usize-1)
#for (V, 0, Vsize-1)
#debug concat ("U2 = ", str(U, 0, 0), ", V2 = ", str(V, 0, 0), "\n")
#local Test = StitchedArray [U][V];
#local Test2 = Test;
#end
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Going for broke here.
Broke what was already broken even broker.
Brokering the breaking.
Breaking badder.
POV-Ray, we have a Segmentation Fault (core dumped)
3 times in a row.
Save your open files before attempting to render.
#############################################
#version 3.7;
global_settings {assumed_gamma 1.0}
#declare U1 = 0;
#declare U2 = tau;
#declare V1 = 0;
#declare V2 = tau;
#declare Phi_inc = (tau/360)*30;
#declare Theta_inc = (tau/360)*10;
#declare Usize = (U2-U1)/Phi_inc;
#declare Vsize = (V2-V1)/Theta_inc;
// Run this as-is, and U goes to 11, and V goes to 35
// NOW
// change The line below to Usize+1, and U goes to 11, and V goes to 36 !!! :O
// How can a variable NOT USED in defining the range of a #for loop change the
behaviour of the loop!
// In BOTH variables!
// Usize is never redefined! W T H
#declare StitchedArray = array[Usize+2][Vsize+1]; // <----- Try it!
#for (U, 0, Usize-1)
#for (V, 0, Vsize-1)
#declare StitchedArray [U][V] = array[4][4];
#end
#end
#declare PatchArray = array [4][4];
#for (Phi, U1, U2, Phi_inc) // 0 to 2pi
#declare U = ceil(Phi/Phi_inc);
#for (Theta, V1, V2, Theta_inc)
#declare V = ceil(Theta/Theta_inc);
#for (Row, 0, 3)
#for (Col, 0, 3)
#declare PatchArray[Row][Col] = <0, 0, 0>;
#end
#end
#debug concat ("U1 = ", str(U, 0, 3), ", V1 = ", str(V, 0, 3), "\n")
#declare StitchedArray [U][V][0][0] = PatchArray[0][0];
#end
#end
#for (U, 0, Usize-1)
#for (V, 0, Vsize-1)
#debug concat ("U2 = ", str(U, 0, 0), ", V2 = ", str(V, 0, 0), "\n")
//#declare Test = StitchedArray [U][V][0][0];
//#declare Test1 = Test;
//#declare Test2 = Test[0][0];
#end
#end
#debug concat(vstr(3, StitchedArray [U][V][0][0], ", ", 0, 3), "\n")
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.08.2018 um 03:05 schrieb Bald Eagle:
> I broke POV-Ray.
> AGAIN.
>
> Stephen, I'm pouring Scotch in my coffee... :|
I'm warning against this workaround, as it only exacerbates the
underlying root cause ;)
> // Run this as-is, and U goes to 11, and V goes to 35
>
> // NOW
>
> // change The line below to Usize+1, and U goes to 11, and V goes to 36 !!! :O
>
> // How can a variable NOT USED in defining the range of a #for loop change the
> behaviour of the loop!
> // In BOTH variables!
> // Usize is never redefined! W T H
PEBCAK Error.
Don't be fooled: The /first/ loop with debug output (recognizable by
printing 3 decimals) /always/ goes to 13 and 36, respectively.
Or rather, it would if it could.
The second loop with debug output (recognizable by printing no decimals)
would always go to 11 and 35, respectively.
The difference is that depending on whether `USize+2` or `USize+1` is
used in the array declaration, POV-Ray may run into an
array-out-of-bounds error when U reaches 13 in the first loop, and never
even start the second loop.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.08.2018 um 03:16 schrieb Bald Eagle:
>
> Going for broke here.
> Broke what was already broken even broker.
> Brokering the breaking.
> Breaking badder.
See? Told you so, Scotch ain't curing the root cause :P
It seems like POV-Ray doesn't like it if you try to access a nested
array that hasn't been initialized. For example:
#declare Foo = array[5];
// "Foo" is now of type "array of yet-undefined type"
#declare Foo[0] = array[4];
// "Foo" is now of type "array of array"
#declare Foo[1][0] = 1;
// "Foo[1]" is still empty, but POV-Ray fails to notice that,
// and tries to access the array it expects to be stored in there.
This bug is present in v3.7.0, and since it wasn't known until now, I'm
not surprised it's still in there.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> PEBCAK Error.
>
> Don't be fooled: The /first/ loop with debug output (recognizable by
> printing 3 decimals) /always/ goes to 13 and 36, respectively.
>
> Or rather, it would if it could.
Christoph,
I do very much respect you, and fully acknowledge and admit that there are
frequently instances where I jump the gun on things, or totally miss what's
happening.
If I'm missing something, then I still can't see it, and I'd like to know how a
#for loop using (12-1)=11 as an endpoint, and yet it runs to 13, or (36-1)=35,
and yet it runs to 36 - is possible.
Beyond the final #end statement, the counter should be final+step. Within the
loop, it should be start to end inclusive (according to the docs)
It would be most helpful if you could point to right where the error is, and
say, "look - it's right HERE" otherwise I'm just wasting a lot of time.
Because I've run it another 5 times with all sorts of other #debug statements,
and the behaviour doesn't make any sense, given what my mind is seeing.
So the question is - what is YOUR mind seeing, and can you demonstrate to me
that it's actually occurring - and WHY.
=========================================================
#version 3.7;
global_settings {assumed_gamma 1.0}
#declare U1 = 0;
#declare U2 = tau;
#declare V1 = 0;
#declare V2 = tau;
#declare Phi_inc = (tau/360)*30;
#declare Theta_inc = (tau/360)*10;
#declare Usize = (U2-U1)/Phi_inc;
#declare Vsize = (V2-V1)/Theta_inc;
// Run this as-is, and U goes to 11, and V goes to 35
// NOW
// change The line below to Usize+1, and U goes to 11, and V goes to 36 !!! :O
// How can a variable NOT USED in defining the range of a #for loop change the
behaviour of the loop!
// In BOTH variables!
// Usize is never redefined! W T H
#debug concat ("Usize = ", str(Usize, 0, 3), ", Vsize = ", str(Vsize, 0, 3),
"\n")
#declare StitchedArray = array[Usize+2][Vsize+2]; // <----- Try it!
#for (U, 0, Usize-1)
#for (V, 0, Vsize-1)
#declare StitchedArray [U][V] = array[4][4];
#end
#end
#declare PatchArray = array [4][4];
#for (Phi, U1, U2, Phi_inc) // 0 to 2pi
#declare U = ceil(Phi/Phi_inc);
#for (Theta, V1, V2, Theta_inc)
#declare V = ceil(Theta/Theta_inc);
#for (Row, 0, 3)
#for (Col, 0, 3)
#declare PatchArray[Row][Col] = <0, 0, 0>;
#end
#end
#debug concat ("U1 = (", str(U, 2, 0), "/", str(Usize, 2, 0), "), V1 = (",
str(V, 2, 0), "/", str(Vsize, 2, 0), ") ")
//#declare StitchedArray [U][V][0][0] = PatchArray[0][0];
#end
#end
#debug "\n\n\n"
#for (U, 0, Usize-1)
#for (V, 0, Vsize-1)
#debug concat ("U2 = (", str(U, 2, 0), "/", str(Usize, 2, 0), "), V2 = (",
str(V, 2, 0), "/", str(Vsize, 2, 0), ") ")
//#declare Test = StitchedArray [U][V][0][0];
//#declare Test1 = Test;
//#declare Test2 = Test[0][0];
#end
#end
#error "end"
//#debug concat(vstr(3, StitchedArray [U][V][0][0], ", ", 0, 3), "\n")
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.08.2018 um 16:04 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
>
>> PEBCAK Error.
I guess I can do better. Sorry for that. It was intended purely humorously.
> If I'm missing something, then I still can't see it, and I'd like to know how a
> #for loop using (12-1)=11 as an endpoint, and yet it runs to 13, or (36-1)=35,
> and yet it runs to 36 - is possible.
>
> Beyond the final #end statement, the counter should be final+step. Within the
> loop, it should be start to end inclusive (according to the docs)
>
> It would be most helpful if you could point to right where the error is, and
> say, "look - it's right HERE" otherwise I'm just wasting a lot of time.
I thought my observations would already be pointing you in the right
direction. I need to have a closer look to provide more assistance.
> So the question is - what is YOUR mind seeing, and can you demonstrate to me
> that it's actually occurring - and WHY.
>
>
> =========================================================
>
>
> #version 3.7;
> global_settings {assumed_gamma 1.0}
>
> #declare U1 = 0;
> #declare U2 = tau;
> #declare V1 = 0;
> #declare V2 = tau;
> #declare Phi_inc = (tau/360)*30;
> #declare Theta_inc = (tau/360)*10;
>
> #declare Usize = (U2-U1)/Phi_inc;
> #declare Vsize = (V2-V1)/Theta_inc;
One thing to note here is that, due to rounding issues, Usize and Vsize
may be non-integer, even though they should be according to mathematics.
Be that as it may - I'll assume Usize and Vsize are exact, in which case
they would be 12 and 36, respectively. The real problem lies elsewhere,
it's just that the computation of Usize and Vsize isn't perfectly kosher
either.
> // Run this as-is, and U goes to 11, and V goes to 35
>
> // NOW
>
> // change The line below to Usize+1, and U goes to 11, and V goes to 36 !!! :O
>
> // How can a variable NOT USED in defining the range of a #for loop change the
> behaviour of the loop!
> // In BOTH variables!
> // Usize is never redefined! W T H
>
> #debug concat ("Usize = ", str(Usize, 0, 3), ", Vsize = ", str(Vsize, 0, 3),
> "\n")
>
> #declare StitchedArray = array[Usize+2][Vsize+2]; // <----- Try it!
> #for (U, 0, Usize-1)
> #for (V, 0, Vsize-1)
> #declare StitchedArray [U][V] = array[4][4];
> #end
>
> #end
The above loop should run from 0 to 11 and 0 to 35, respectively.
Note however that this only StitchedArray up to index 11 and 35,
respectively, whereas the next loop - even if running properly - seems
to be designed to access StitchedArray up to index 12 and 36, which may
bite you even after cleaning out the problem currently at hand.
> #declare PatchArray = array [4][4];
>
> #for (Phi, U1, U2, Phi_inc) // 0 to 2pi
> #declare U = ceil(Phi/Phi_inc);
This is dangerous, as you're using a non-integral loop variable with a
non-integral stepping, and it may not exactly end up at U2 even though
mathematically it should. The loop may run sort or long, i.e. Phi may
end up anywhere between U2-Phi_inc+epsilon to U2+Phi_inc-epsilon.
The resulting Phi/Phi_inc should nominally be 12, but may be anywhere
between 12-1+epsilon = 11+epsilon to 12+1-epsilon = 13-epsilon.
Taking the ceil of the value will bump your 11+epsilon to 12, but it
will also bump 13-epsilon to 13.
And indeed in practice the outer loop will happily run from 0 to 13, not
12 as you would expect. If the array is declared of size Usize+2 = 12+2
= 14, index 13 exists and therefore the loop runs without an obvious
hitch. If the array is instead declared of size Usize+1 = 12+1 = 13,
index 13 is out of bounds and you get a parse error (or even a crash)
trying to access it.
And that, I guess, is pretty much everything there is to it.
I recommend using `U = ceil(Phi/Phi_inc - 0.5)` or some such, i.e.
proper rounding.
Or maybe better still, use U and V as the loop variables, and from those
compute the angle, rather than vice versa.
The inner loop happens to be less of a problem, and it is running from
V=0 to V=36 as intended, but that is probably just coincidence. Change
Theta_inc, and you may get just as bad behaviour as with the outer loop.
> #for (U, 0, Usize-1)
> #for (V, 0, Vsize-1)
> #debug concat ("U2 = (", str(U, 2, 0), "/", str(Usize, 2, 0), "), V2 = (",
> str(V, 2, 0), "/", str(Vsize, 2, 0), ") ")
> //#declare Test = StitchedArray [U][V][0][0];
> //#declare Test1 = Test;
> //#declare Test2 = Test[0][0];
> #end
>
> #end
This loop is better behaved, because Usize-1 seems to be a proper nut,
and you're using integer stepping. As a consequence, it runs from 0 to
11 and 0 to 35, respectively, as intended.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> >> PEBCAK Error.
>
> I guess I can do better. Sorry for that. It was intended purely humorously.
Indeed. Still accurate. ;)
> ....the next loop - even if running properly - seems
> to be designed to access StitchedArray up to index 12 and 36, which may
> bite you even after cleaning out the problem currently at hand.
> This is dangerous, as you're using a non-integral loop variable with a
> non-integral stepping, and it may not exactly end up at U2 even though
> mathematically it should. The loop may run sort or long, i.e. Phi may
> end up anywhere between U2-Phi_inc+epsilon to U2+Phi_inc-epsilon.
>
> The resulting Phi/Phi_inc should nominally be 12, but may be anywhere
> between 12-1+epsilon = 11+epsilon to 12+1-epsilon = 13-epsilon.
> I recommend using `U = ceil(Phi/Phi_inc - 0.5)` or some such, i.e.
> proper rounding.
Which is "wrong" according to some, but if it works, it'll be fine. :)
> Or maybe better still, use U and V as the loop variables, and from those
> compute the angle, rather than vice versa.
"Your code was crap, and didn't anyone ever tell you not to do things like
that?"
"The pile of code accumulated as a result of your excremental coding practices
was giving off a pile of steam that was obscuring a logical view of the
problem."
"GIVE ME THAT."
(grabs code and hurls the offending parts in the bit bucket)
"Here."
#for (U, 0, Usize-1)
#for (V, 0, Vsize-1)
#declare Phi = (U*Phi_inc);
#declare Theta = (V*Theta_inc);
Much more better.
And now back to the funnerer stuff.
------------------------------------------------
Today's daily summary:
Broke POV-Ray with a previously unknown bug.
("That's why we let you sit at the Adult keyboard, BE, No one breaks things as
well or as often as you do.")
Spurred good ole' jr to do some fancy array-slinging and show off a bit.
(I think he can do better ;) )
Learned NOT TO DO THAT. EVER AGAIN.
That plus a host of other things made today annoying and arduous, but
well-spent.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27-8-2018 23:58, Bald Eagle wrote:
> Today's daily summary:
>
> Broke POV-Ray with a previously unknown bug.
> ("That's why we let you sit at the Adult keyboard, BE, No one breaks things as
> well or as often as you do.")
> Spurred good ole' jr to do some fancy array-slinging and show off a bit.
> (I think he can do better ;) )
> Learned NOT TO DO THAT. EVER AGAIN.
>
> That plus a host of other things made today annoying and arduous, but
> well-spent.
>
[patting bald head]
Good boy. Now, you can have your coffee. :-)
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
