On 24/11/2010 9:00 PM, clipka wrote:
>
> Let it be known to him that We have decided to grant him the mercy of
> accepting his apology.
>
> :-)

LOL


-- 
Regards
     Stephen

Post a reply to this message

> <jeb### [at] freefr> wrote:

>  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.
>

In addition to this correction, I believe it would be helpful to have the 2nd
paragraph explicitly state that, when using no #breaks, a *series*
of #case's or #range's can produce 'cascading TRUE' behavior. (As I found out in
my example.) The WIKI calls it a 'slip-through' if I'm not mistaken. To most
folks in the POV-Ray community this is probably obvious--from the
wording of the docs above or from other coding experience. But I just didn't
grasp it that way initially (am I alone?)

Something like,
"For example, if you use a series of #case or #range clauses with no #breaks
in-between, the first clause that evaluates TRUE will force all subsequent
clauses to evaluate TRUE as well (regardless of their intrinsic TRUE/FALSE
conditional state), in a sort of cascade--until a #break/#else/#end is
encountered." Or something similar.

That might sound like I'm 'dumbing-down' the documentation; but with such an
addition, I would probably have understood these concepts better, from the
get-go.

Ken

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> Something like,
> "For example, if you use a series of #case or #range clauses with no #breaks
> in-between, the first clause that evaluates TRUE will force all subsequent
> clauses to evaluate TRUE as well (regardless of their intrinsic TRUE/FALSE
> conditional state), in a sort of cascade--until a #break/#else/#end is
> encountered." Or something similar.
>

And this 'cascade effect' can also affect the behavior of #else, kind of a
'gotcha' (as I discovered, now that I halfway-know what I'm doing!)  I'll use
the "N=prime" code as an example (with a few additions of my own)...

#declare N = 6;
#switch(N)
       #case(2)
         // if 2, do this
         #debug "I like this number a lot!\n"
       #case(3)
       #case(5)
       #case(7)
         // if 2, 3, 5, or 7, do this
         #debug "N is prime\n"
       #break
       #range(0,10)
         #debug "N is non-prime\n"
       #range(20,30)
         #debug "range(20,30) is also TRUE\n"
       #range(40,50)
         #debug "range(40,50) is also TRUE\n"
       // #break
       #else // do this for anything over 10
         #debug "Oops, I don't know the primes >10 by heart\n"
     #end

Note that I purposely commented-out the final #break clause. (I say this because
initially, I didn't think it was necessary. But it is.)

The docs about #else say, "It is only executed if the clause before it was a
false clause."

Let's say N=6. The first clause to be evaluated TRUE is #range(1,10). Now
without thinking, it might appear that the final #range(40,50) would be
evaluated false (because N doesn't fall in its range). But because of the
'cascading TRUES' of the #ranges above it, it's actually TRUE. And, continuing,
the #else conditional in this case is also forced TRUE (if that's the correct
term), and #else's token is also printed to messages. So the #break clause
before #else is a necessity, to get an expected outcome from it.

What this shows me is that #else is 'just another conditional', not the *special
keyword with its own rules* that I've always thought it to be. (In a manner of
speaking, I thought #else had its own 'implied' #break preceding it.)

I learn something new every day...

Ken

Post a reply to this message

Kenneth wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote:
> 
>> Something like,
>> "For example, if you use a series of #case or #range clauses with no #
breaks
>> in-between, the first clause that evaluates TRUE will force all subseq
uent
>> clauses to evaluate TRUE as well (regardless of their intrinsic TRUE/F
ALSE
>> conditional state), in a sort of cascade--until a #break/#else/#end is

>> encountered." Or something similar.
>>
> 
> And this 'cascade effect' can also affect the behavior of #else, kind o
f a
> 'gotcha' (as I discovered, now that I halfway-know what I'm doing!)  I'
ll use
> the "N=prime" code as an example (with a few additions of my own)...
> 
> #declare N = 6;
> #switch(N)
>        #case(2)
>          // if 2, do this
>          #debug "I like this number a lot!\n"
>        #case(3)
>        #case(5)
>        #case(7)
>          // if 2, 3, 5, or 7, do this
>          #debug "N is prime\n"
>        #break
>        #range(0,10)
>          #debug "N is non-prime\n"
>        #range(20,30)
>          #debug "range(20,30) is also TRUE\n"
>        #range(40,50)
>          #debug "range(40,50) is also TRUE\n"
>        // #break
>        #else // do this for anything over 10
>          #debug "Oops, I don't know the primes >10 by heart\n"
>      #end
> 
> Note that I purposely commented-out the final #break clause. (I say thi
s because
> initially, I didn't think it was necessary. But it is.)
> 
> The docs about #else say, "It is only executed if the clause before it 
was a
> false clause."
> 
> Let's say N=6. The first clause to be evaluated TRUE is #range(1,10).
 Now
> without thinking, it might appear that the final #range(40,50) would be

> evaluated false (because N doesn't fall in its range). But because of t
he
> 'cascading TRUES' of the #ranges above it, it's actually TRUE. And, con
tinuing,
> the #else conditional in this case is also forced TRUE (if that's the c
orrect
> term), and #else's token is also printed to messages. So the #break cla
use
> before #else is a necessity, to get an expected outcome from it.
> 
	The doc explicitly states the opposite: "parsing continues until a
#break, *#else* or #end directive is reached", so this is a bug
(either in povray or in the docs).

		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)

On 11/25/2010 02:24 PM, "Jérôme M. Berger" wrote:
> The doc explicitly states the opposite: "parsing continues until a
> #break, *#else* or #end directive is reached", so this is a bug
> (either in povray or in the docs).
> 
> 		Jerome

There was a bug discovered with the #break directive behavior that was
addressed (with enhancements) by Change 4942 on 2010/04/18 by
clipka@cli-pc-xp64 ... I believe things "jive" now

Post a reply to this message

> <jeb### [at] freefr> wrote:

>  The doc explicitly states the opposite: "parsing continues until a
> #break, *#else* or #end directive is reached", so this is a bug
> (either in povray or in the docs).
>

Yeah, I have to admit that I was a bit mystified by the docs (and WIKI) on this
point. But then again, I was muddying the issue somewhat by doing my test in
*old* v3.6.1--while expecting the behavior to jive with the latest WIKI info
(and beta changes.)

Ken

Post a reply to this message

Jim Holsenback <jho### [at] povrayorg> wrote:
> On 11/25/2010 02:24 PM, "Jérôme M. Berger" wrote:
> > The doc explicitly states the opposite: "parsing continues until a
> > #break, *#else* or #end directive is reached", so this is a bug
> > (either in povray or in the docs).
> >
>
> There was a bug discovered with the #break directive behavior that was
> addressed (with enhancements) by Change 4942 on 2010/04/18 by
> clipka@cli-pc-xp64 ... I believe things "jive" now

Thanks, Jim. (Clipka's Change 4942 is quoted verbatim in the WIKI, I believe.)

So, just so I understand POV's *current* behavior (beta 39): The need for a
#break before #else is *no longer* necessary to avoid the 'cascading
TRUE behavior? I.e., (as a simple analogy) does #else now have an 'implied'
#break before it? Sorry, I'm still having a bit of trouble understanding change
4942 if there's NO #break before an #else.

I guess one easy way to find out would be to run my 'missing #break before
#else' code test in beta 39, to see what happens. Could..uh..someone do that?
:-)

Ken

Post a reply to this message

Am 26.11.2010 08:50, schrieb Kenneth:
> Jim Holsenback<jho### [at] povrayorg>  wrote:
>>
>> There was a bug discovered with the #break directive behavior that was
>> addressed (with enhancements) by Change 4942 on 2010/04/18 by
>> clipka@cli-pc-xp64 ... I believe things "jive" now
>
> Thanks, Jim. (Clipka's Change 4942 is quoted verbatim in the WIKI, I believe.)

Doesn't seem like that. Original description of change #4942 was as follows:

---------------------
[smp] modified #break semantics; the #break directive can now be used...:

- anywhere within a #case or #range block, to skip to the end of the 
#switch directive (previously, #break was only useful right before the 
next #case, #range or #else directive, to indicate that a slip-through 
was not desired);

- anywhere within a loop block (both #while and #for), to preliminarily 
terminate the loop; and

- anywhere within a #macro block, to preliminarily terminate the macro.

Example for the use in a loop:

#local R = seed(4711);
#for (I, 1, 100)
   #if (rand(R) < I/1000)
     #break // terminate loop early
   #end
   #debug concat(str(I,0,0), " iterations and counting\n")
#end

Where multiple #switch, loop and/or #macro blocks are nested, #break 
will leave only the innermost of these.
---------------------

> So, just so I understand POV's *current* behavior (beta 39): The need for a
> #break before #else is *no longer* necessary to avoid the 'cascading
> TRUE behavior? I.e., (as a simple analogy) does #else now have an 'implied'
> #break before it? Sorry, I'm still having a bit of trouble understanding change
> 4942 if there's NO #break before an #else.

The wording in the Wiki is wrong; in a #switch statement, #else acts 
like a #range that encompasses any possible number (*), i.e. the 
preceding #case or #range must be ended with a #break statement if 
execution should not continue into the #else block.

(* This analogy even goes so far that it is legal - though perfectly 
useless - to place additional #case or #range statements after an #else 
block; even additional #else blocks will not cause POV-Ray to complain. 
Note that this applies only to switch statements though.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 26.11.2010 08:50, schrieb Kenneth:

> > Thanks, Jim. (Clipka's Change 4942 is quoted verbatim in the WIKI, I believe.)
>
> Doesn't seem like that. Original description of change #4942 was as follows:

Sorry, you're right. (In all the cross-referencing I was doing between various
WIKI pages/3.6.1 docs/beta-test page at POV-Ray.org, I got a bit confused!)
>
> > I.e., (as a simple analogy) does #else now have an 'implied'
> > #break before it?
>
> The wording in the Wiki is wrong; in a #switch statement, #else acts
> like a #range that encompasses any possible number (*), i.e. the
> preceding #case or #range must be ended with a #break statement if
> execution should not continue into the #else block.

Thanks; well-put, and completely clarified now. (This would make a good addition
to the WIKI, too.)

Ken

Post a reply to this message

On 11/27/2010 09:41 AM, Kenneth wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 26.11.2010 08:50, schrieb Kenneth:
> 
>>> Thanks, Jim. (Clipka's Change 4942 is quoted verbatim in the WIKI, I believe.)
>>
>> Doesn't seem like that. Original description of change #4942 was as follows:
> 
> Sorry, you're right. (In all the cross-referencing I was doing between various
> WIKI pages/3.6.1 docs/beta-test page at POV-Ray.org, I got a bit confused!)
>>
>>> I.e., (as a simple analogy) does #else now have an 'implied'
>>> #break before it?
>>
>> The wording in the Wiki is wrong; in a #switch statement, #else acts
>> like a #range that encompasses any possible number (*), i.e. the
>> preceding #case or #range must be ended with a #break statement if
>> execution should not continue into the #else block.
> 
> Thanks; well-put, and completely clarified now. (This would make a good addition
> to the WIKI, too.)
> 
> Ken
> 
> 
> 
certainly a lot of bandwidth over something that should have been a
trivial matter ... done

Post a reply to this message