[relates to v3.6.1]

In trying to use #switch and #case in a #while-loop--and NOT using #break
in-between the several #case clauses--I get behavior that I don't understand (a
long-standing puzzle to me, actually.) That is, I don't understand the behavior
if I'm correctly reading the documentation at 3.2.2.6.3

Here's my simple code example :

#declare counter = 1;
union{
#while(counter <=3)
box{0,1
 #switch(counter)
 #case(1) scale 1
 #case(2) scale .5
 #case(3) scale .3
 //#else
 #end
 translate 1*counter*y
   }
#declare counter = counter + 1;
#end
 texture{...}
     }

I assume that I'm using #switch and #case correctly(?) in that I can use a
variable for #switch(), while giving each #case() its own exclusive set value to
compare it to.

What I expected the code to do was simply scale each box individually, and only
once, according to the value of counter. Seems simple enough--but that's not
what happens. As far as I can tell, box 1 is being scaled THREE times (by all
three successive #case clauses), box 2 is scaled TWICE, and box 3 is scaled
once. (My reason for leaving out the #break clauses is basic laziness--less
typing--but more than that, the docs tell me that they aren't necessary in such
an example. Therein lies the problem, apparently; either I'm just reading the
docs WRONG WRONG WRONG, or the wording isn't clear or accurate.)

The other oddity is this: If I keep the #case() clauses as they are, but reduce
the #while loop to #while(counter <= 2), the two boxes still get scaled by
#case(3).

BTW, I took a look at section 2.5 in the WIKI, about the new uses of #break
(introduced in one of the 3.7 betas), but what I see there doesn't seem to
affect my basic question.

*HOWEVER*, while writing this post, I now see that there might be two
mutually-exclusive explanations of how #case/#break directives work, in two
different places in the WIKI:

http://wiki.povray.org/content/Documentation:Reference_Section_2.5
says, "If a clause evaluates true but no #break is specified, the parsing will
fall through to the next #case or #range and that clause conditional is
evaluated." [This seems clear to me--it's the behavior I expected, as the
wording is the same in the v3.6.1 included documentation.]

whereas at
http://wiki.povray.org/content/HowTo:Use_conditional_structures
it says, "When processing a matching #case or #range clause, if a #break is not
encountered it continues through successive #case statements whether they match
or not." [This would, I think, explain the behavior I'm seeing; so this must be
the accurate explanation.]

An honestly naive question:  Which mode of operation *should* be correct,
compared to other standard computational languages?

Ken

Post a reply to this message

Le 22/11/2010 11:40, Kenneth a écrit :
> An honestly naive question:  Which mode of operation *should* be correct,
> compared to other standard computational languages?
> 
Both are correct and doing as usual in povray.
(They say the same for me)
The first one is nevertheless more prone to error of interpretation
(because "clause conditional" does not refer to #case/#range (clause)
but to the block (conditional) that is under the #case/#range clause,
even if false)

Traditional computational languages behave the same way:
 when no break, the instructions continue on the following lines.
It's an old tradition.
(a switch/case/break can be rewritten with if/table & goto... including
a goto to exit the switch block (as break): no break, no jump.

Post a reply to this message

On 11/22/2010 06:40 AM, Kenneth wrote:
> *HOWEVER*, while writing this post, I now see that there might be two
> mutually-exclusive explanations of how #case/#break directives work, in two
> different places in the WIKI:
> 
> http://wiki.povray.org/content/Documentation:Reference_Section_2.5
> says, "If a clause evaluates true but no #break is specified, the parsing will
> fall through to the next #case or #range and that clause conditional is
> evaluated." [This seems clear to me--it's the behavior I expected, as the
> wording is the same in the v3.6.1 included documentation.]

If you're using 3.7betas (for some reason i think/thought you were)
there has been a change in behavior noted here:

http://wiki.povray.org/content/Documentation:Tutorial_Section_1#Changes_and_New_Features_Summary

search for (browser find) break on that page, and the link will
eventually get you to the page you mentioned above. This is our MOST up
to date documentation as with regards to v3.7 ....

> 
> whereas at
> http://wiki.povray.org/content/HowTo:Use_conditional_structures
> it says, "When processing a matching #case or #range clause, if a #break is not
> encountered it continues through successive #case statements whether they match
> or not." [This would, I think, explain the behavior I'm seeing; so this must be
> the accurate explanation.]
> 
> An honestly naive question:  Which mode of operation *should* be correct,
> compared to other standard computational languages?

this page shows last update 10June2008 (very bottom of the page) so I'd
consider this page suspect ... I didn't review the page for accuracy,
but since the last update was a bit ago I think it's a fairly safe
assumption that there is/may be some inconsistencies

Post a reply to this message

Le_Forgeron wrote:
> Traditional computational languages behave the same way:
>  when no break, the instructions continue on the following lines.
> It's an old tradition.
> (a switch/case/break can be rewritten with if/table & goto... including

> a goto to exit the switch block (as break): no break, no jump.
> 
	Not really. Both behaviours may be seen in traditional languages: C
and its descendants (C++, Java, etc) behave like that, but other
languages behave as if there was a break for each case (this
includes Basic, Pascal and its descendants and most functional
languages if I'm not mistaken).

		Jerome
-- 
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Am 22.11.2010 11:40, schrieb Kenneth:

> *HOWEVER*, while writing this post, I now see that there might be two
> mutually-exclusive explanations of how #case/#break directives work, in two
> different places in the WIKI:
>
> http://wiki.povray.org/content/Documentation:Reference_Section_2.5
> says, "If a clause evaluates true but no #break is specified, the parsing will
> fall through to the next #case or #range and that clause conditional is
> evaluated." [This seems clear to me--it's the behavior I expected, as the
> wording is the same in the v3.6.1 included documentation.]
>
> whereas at
> http://wiki.povray.org/content/HowTo:Use_conditional_structures
> it says, "When processing a matching #case or #range clause, if a #break is not
> encountered it continues through successive #case statements whether they match
> or not." [This would, I think, explain the behavior I'm seeing; so this must be
> the accurate explanation.]
>
> An honestly naive question:  Which mode of operation *should* be correct,
> compared to other standard computational languages?

The switch syntax appears to mimick the syntax of C, which also uses the 
"slip-thru" concept, i.e. if you don't insert a "break;", the next block 
of statements will be executed even if the case value doesn't match.

C++, Java, JavaScript and C# also use this concept (no surprise though, 
as they all have inherited a lot of syntax from C).

The idea behind this is that you can write stuff like:

     #switch(N)
       #case(2)
       #case(3)
       #case(5)
       #case(7)
         #debug "N is prime\n"
         #break
       #range(0,10)
         #debug "N is non-prime\n"
         #break
       #else
         #debug "I don't know the primes >10 by heart\n"
     #end

It should be noted that the Missing Break Error is a well-known source 
of bugs in C-derived languages, so the fact that it's in these languages 
is in no way a sign of quality ;-)

Post a reply to this message

clipka wrote:
> C++, Java, JavaScript and C# also use this concept 

FWIW, C# is different. Each section of the switch has to end in either a 
break or a goto, and if you want "fallthrough", you goto a different case 
label. Best of both worlds: you get to share cases if you want, but the 
cases are still independent, so you can (for example) rearrange them without 
breaking your code.

Plus, you don't get to do things like put while loops around the cases but 
inside the switch. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Jim Holsenback <jho### [at] povrayorg> wrote:

> If you're using 3.7betas (for some reason i think/thought you were)
> there has been a change in behavior noted here:
>
>
http://wiki.povray.org/content/Documentation:Tutorial_Section_1#Changes_and_New_Features_Summary
>
> search for (browser find) break on that page, and the link will
> eventually get you to the page you mentioned above. This is our MOST up
> to date documentation as with regards to v3.7 ....

I'm still with 3.6.1c (but I assume that the *basic* operation of #case/#break
hasn't changed since then?)

If the link you mentioned is the latest WIKI documentation, it matches most of
the wording in my 3.6.1 included documentation, and is the prime source of my
puzzlement. Here's why:

The WIKI (updated 14 October 2010) at
http://wiki.povray.org/content/Documentation:Reference_Section_2.5#The_.23switch.2C_.23case.2C_.
23range_and_.23break_Directives

says, "if the [#case} clause's condition is true, that clause's tokens are
parsed normally and parsing continues until a #break, #else or #end directive is
reached. If the condition is false, POV-Ray skips until another #case or #range
is found."

and

"If a clause evaluates true but no #break is specified, the parsing will fall
through to the next #case or #range and that clause conditional is evaluated."

The words 'skip' and 'evaluate' seem clear and co-consistent as to what *should*
happen (*IF* I'm understanding them correctly.) Here's how I read the quoted
statements in relation to the simple code example I posted:

Given:

#while(counter <=3) and the situation where counter actually equals 2,

I would expect that, without using any #breaks, #case(1) would be 'evaluated' as
FALSE and 'skipped' (no action there), leading to #case(2) being 'evaluated' as
TRUE, then #case(3) being 'evaluated' as FALSE and 'skipped'--with the sum total
of these evaluations being that only the #case(2) scaling (its token) is applied
to my box, as it's the only TRUE evaluation. But this isn't what happens;
instead, the behavior *seems* to match the outdated(?) WIKI section that says,
"When processing a matching #case or #range clause, if a #break is not
encountered it continues through successive #case statements whether they match
or not." I.e., any following #case() tokens are applied whether those #cases are
TRUE *or* FALSE.

See my conundrum? Of course, my little code problem can easily be fixed with
some #break clauses. But I'm FAR more concerned with my own lack of
understanding of the logic of this situation.

Ken

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Le 22/11/2010 11:40, Kenneth a écrit :
> > An honestly naive question:  Which mode of operation *should* be correct,
> > compared to other standard computational languages?
> >
> Both are correct and doing as usual in povray.
> (They say the same for me)
> The first one is nevertheless more prone to error of interpretation
> (because "clause conditional" does not refer to #case/#range (clause)
> but to the block (conditional) that is under the #case/#range clause,
> even if false)

If that's the case--no pun intended ;-) --then the wording certainly needs
changing and clarification, IMO. The phrase (or idea of) 'conditional clause',
and possibly the word 'evaluate,' would appear to have unintended multiple
meanings there--at least to *this* poor struggling soul. :-(

Post a reply to this message

On 11/22/2010 08:59 PM, Kenneth wrote:
> See my conundrum? Of course, my little code problem can easily be fixed with
> some #break clauses. But I'm FAR more concerned with my own lack of
> understanding of the logic of this situation.

Doesn't the 2nd "Note:" in the previously mentioned wiki passage,
particularly ... "(previously, #break was only useful right before the
next #case, #range or #else directive, to indicate that a slip-through
was not desired)." ... offer any clarity?

Post a reply to this message

Kenneth wrote:
> Jim Holsenback <jho### [at] povrayorg> wrote:
> 
>> If you're using 3.7betas (for some reason i think/thought you were)
>> there has been a change in behavior noted here:
>>
>> http://wiki.povray.org/content/Documentation:Tutorial_Section_1#Change
s_and_New_Features_Summary
>>
>> search for (browser find) break on that page, and the link will
>> eventually get you to the page you mentioned above. This is our MOST u
p
>> to date documentation as with regards to v3.7 ....
> 
> I'm still with 3.6.1c (but I assume that the *basic* operation of #case
/#break
> hasn't changed since then?)
> 
> If the link you mentioned is the latest WIKI documentation, it matches 
most of
> the wording in my 3.6.1 included documentation, and is the prime source
 of my
> puzzlement. Here's why:
> 
> The WIKI (updated 14 October 2010) at
> http://wiki.povray.org/content/Documentation:Reference_Section_2.5#The_
.23switch.2C_.23case.2C_.
> 23range_and_.23break_Directives
> 
> says, "if the [#case} clause's condition is true, that clause's tokens 
are
> parsed normally and parsing continues until a #break, #else or #end dir
ective is
> reached. If the condition is false, POV-Ray skips until another #case o
r #range
> is found."
> 
> and
> 
> "If a clause evaluates true but no #break is specified, the parsing wil
l fall
> through to the next #case or #range and that clause conditional is eval
uated."
> 
> The words 'skip' and 'evaluate' seem clear and co-consistent as to what
 *should*
> happen (*IF* I'm understanding them correctly.) Here's how I read the q
uoted
> statements in relation to the simple code example I posted:
> 
	You're right, there is a mistake in the doc. The first statement is
correct: if the condition is true, then parsing continues until a
#break, #else or #end (unless that #break, #else or #end is
associated with another control statement such as #if or #while).

	The second statement is wrong: when the parsing falls through to
the next #case or #range, that clause conditional is *ignored* and
the following statements are parsed as if the conditional were true.

	The problem here is with the word "conditional". The docs should
either contain a formulation similar to what I wrote above or use
the word "body" instead of "conditional".

		Jerome
-- 
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)