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

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