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)

In article <web.4ceb0f2c2f7b65a8196b08580@news.povray.org>,
Kenneth <kdw### [at] earthlinknet> 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.

Simplest way to look at it - successive cases with no break are all
OR'ed together.

"case" means "If this case OR any of the preceding cases in this block
since the last break are true, execute this code"

This lets you conserve code by grouping a bunch of different cases
together.  See the "N is prime" example from clipka.  But you could
also ADD code for #case(2) that only executes for that, without
separating it out of the conditions for 3,5 and 7:

       #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)
         // if 0-10 and NOT 2,3,5,7 (because of the "break" above) do this
         #debug "N is non-prime\n"
         #break
       #else
         #debug "I don't know the primes >10 by heart\n"
     #end

    tom

Post a reply to this message

Jim Holsenback <jho### [at] povrayorg> wrote:
> 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?

I wish I could say YES, but... :-(

"...a slip through was not desired" didn't make much sense to me either, since I
couldn't make real sense of the overall descriptions...

Although, it's now starting to sink in, finally. :-)

Ken

Post a reply to this message

fin### [at] head-cfaharvardedu (Thomas A. Fine) wrote:

> Simplest way to look at it - successive cases with no break are all
> OR'ed together.
>
> "case" means "If this case OR any of the preceding cases in this block
> since the last break are true, execute this code"
>
> This lets you conserve code by grouping a bunch of different cases
> together.  See the "N is prime" example from clipka.  But you could
> also ADD code for #case(2) that only executes for that, without
> separating it out of the conditions for 3,5 and 7:

That is a beautiful and clear description (and code example) of how it all
works--MANY thanks! (It's also a great little piece of experimental code for me
--I've been playing around with it, to get a clearly-understandable 'feel' for
what goes on.) And it shows me that I sure had a muddled *quasi*-understanding
of it all, before now. Geez, I sure was clueless...

IMO, your comments and code example would make a great addition to the WIKI
(hint, hint!)

Ken

Post a reply to this message

On 11/23/2010 10:05 PM, Kenneth wrote:
> IMO, your comments and code example would make a great addition to the WIKI
> (hint, hint!)

ah then ... a perfect opportunity for you to bolster your understanding
by having a go at the howto article you mentioned in your original post ;-)

Post a reply to this message

In article <web.4ceb0f2c2f7b65a8196b08580@news.povray.org>,
Kenneth <kdw### [at] earthlinknet> 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.

Simplest way to look at it - successive cases with no break are all
OR'ed together.

"case" means "If this case OR any of the preceding cases in this block
since the last break are true, execute this code"

This lets you conserve code by grouping a bunch of different cases
together.  See the "N is prime" example from clipka.  But you could
also ADD code for #case(2) that only executes for that, without
separating it out of the conditions for 3,5 and 7:

       #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)
         // ELSE if 0-10 do this   ("break" is sort of like "else")
         #debug "N is non-prime\n"
         #break
       #else
         #debug "I don't know the primes >10 by heart\n"
     #end

    tom

Post a reply to this message

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

> That is a beautiful and clear description (and code example) of how it all
> works--MANY thanks! (It's also a great little piece of experimental code for me
> --I've been playing around with it, to get a clearly-understandable 'feel' for
> what goes on.)

Ooh, this is embarrassing: I just realized that Clipka had posted the basic "N
is prime" code here earlier (and I wasn't paying good attention--I was too
wrapped up in minutia.) So...thanks to Thomas AND Clipka :-)  (How's *that* for
diplomacy?!)

Ken

Post a reply to this message

Jim Holsenback <jho### [at] povrayorg> wrote:
> On 11/23/2010 10:05 PM, Kenneth wrote:
> > IMO, your comments and code example would make a great addition to the WIKI
> > (hint, hint!)
>
> ah then ... a perfect opportunity for you to bolster your understanding
> by having a go at the howto article you mentioned in your original post ;-)

Well, I guess I should have expected that ;-)

You mean the how-to article I mentioned(?) in this post (did I?)--or one of the
many *others* that I said I was gonna write, on other topics? Yeah,
well....um...

Actually, I *have* been mulling over all that's been said here so far, and
comparing it to what the docs say, and may yet have a go at trying to re-word
part of the docs/WIKI-- if only to satisfy my *own* sense of clarity.
(Admittedly from a 'non-programmer's' rather naive viewpoint.) Yet it might
prove useful to others, I suppose.  I have some ideas that are starting to
gel--but I'm realizing that indeed it *is* difficult to put these #case/#break
concepts into simpler, more succinct form. Need to think on it a bit more...

Ken

Post a reply to this message

Am 24.11.2010 19:28, schrieb Kenneth:

> Ooh, this is embarrassing: I just realized that Clipka had posted the basic "N
> is prime" code here earlier (and I wasn't paying good attention--I was too
> wrapped up in minutia.) So...thanks to Thomas AND Clipka :-)  (How's *that* for
> diplomacy?!)

Let it be known to him that We have decided to grant him the mercy of 
accepting his apology.

:-)

Post a reply to this message