 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 17-11-08 à 15:56, Kenneth a écrit :
> SO...
> With all of this new-found knowledge, I actually came up with some code that
> works consistently-- and that still uses my original OR statements(!)
>
> #switch(1)
> #case(
> (strcmp(IMG_TYPE,AA)=0) // if strcmp(...) returns zero, then 0=0 is 'true',
> // which matches #switch. Otherwise, 'false'.
> | (strcmp(IMG_TYPE,BB)=0) // ditto
> | (strcmp(IMG_TYPE,CC)=0) // ditto
>
> This construct also works in my real scene code, I'm happy to say. (And with the
> ORs in any order.) I prefer the ORs because the real scene has numerous #case
> clauses, each with four or five strcmp()s. It all simply looks more compact
> this way, to my eyes.
>
> It's all starting to make sense to me now (although I still need to digest some
> of the comments.) I also see that there are, as usual, various ways to get
> similar results.
>
> THANKS for taking the time with the insights, examples, and discussion! (And if
> I'm still not 'getting it', don't hesitate to say so!)
>
>
>
>
Want something even more compact?
Try this :
(!strcmp(IMG_TYPE,AA))|(!strcmp(IMG_TYPE,BB))|(!strcmp(IMG_TYPE,CC))
The "!" is the NOT operator. If the value is zero, it becomes a 1, if
it's <>0, it becomes a 0.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <kua### [at] videotron ca> wrote:
>
> Want something even more compact?
Ah, yes indeed, that works as well-- and IS more compact. I'm familiar with
"not", but it would never have occured to me to use it in this context...until
now ;-)
Your example (and your other comments) have helped me to further understand the
nature of my original problem. Very much appreciated.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
After re-reading the various comments, and experimenting with all sorts of
combinations of things, I have to admit that all of this stuff is still a bit
difficult to wrap my mind around-- mainly because there's a specific stumbling
block or two that's giving me a problem.
I've come up with some examples that probably go to the root cause of my
remaining misunderstanding.
My basic question is: When is the #switch() value considered an actual Boolean
true/false value, vs. a 'simple numerical' value?
Getting back to basics-- e.g., NOT using the strcmp() string-compare function to
complicate things-- consider the following:
#declare C = 27;
(A)
This works successfully...
#switch(1) // Boolean 'true'
#case(C = 27) // a Boolean comparison that's also 'true'
(B)
This ALSO works... two 'numerical values' that match
#switch(27)
#case(C)
(C)This does NOT work (it falls through to the #else clause)...
#switch(1000) // or 343 or -89 or any other non-zero value
#case(C = 27) // the Boolean comparison again
Regarding (A) and (B), it appears that #switch 'changes its operational mode'--
depending on the particular 'kind' of #case that it's presented with (Boolean
true/false vs. a simple number.) Currently, I'm not exactly sure when that might
happen, given the complexities of all of this inter-related stuff.
Regarding (C), I was under the impression from some earlier comments that
#switch could use ANY positive/negative value to mean 'true' or (1)-- but that
doesn't seem to be a correct interpretation. It seems that only #switch(1)
works.
If I could just get past *these* misunderstandings, my world would be a MUCH
happier place to be in ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
On 10/11/2017 21:15, Kenneth wrote:
> After re-reading the various comments, and experimenting with all sorts of
> combinations of things, I have to admit that all of this stuff is still a bit
> difficult to wrap my mind around-- mainly because there's a specific stumbling
> block or two that's giving me a problem.
> I've come up with some examples that probably go to the root cause of my
> remaining misunderstanding.
I'll try.
> My basic question is: When is the #switch() value considered an actual Boolean
> true/false value, vs. a 'simple numerical' value?
the documentation only refers to float values being compared/used.
> Getting back to basics-- e.g., NOT using the strcmp() string-compare function to
> complicate things-- consider the following:
> #declare C = 27;
> (A)
> This works successfully...
> #switch(1) // Boolean 'true'
> #case(C = 27) // a Boolean comparison that's also 'true'
yes, you say "switch when the value is one", and "truth" happens to be
represented as one, so, bingo.
> (B)
> This ALSO works... two 'numerical values' that match
> #switch(27)
> #case(C)
same thing, only now you say "switch when the value is 27".
> (C)This does NOT work (it falls through to the #else clause)...
> #switch(1000) // or 343 or -89 or any other non-zero value
> #case(C = 27) // the Boolean comparison again
how could it? 1000 is not the same as one.
> Regarding (A) and (B), it appears that #switch 'changes its operational mode'--
> depending on the particular 'kind' of #case that it's presented with (Boolean
> true/false vs. a simple number.) Currently, I'm not exactly sure when that might
> happen, given the complexities of all of this inter-related stuff.
again, the Boolean stuff just happens to apply in these "corner cases".
think coincidence.
> Regarding (C), I was under the impression from some earlier comments that
> #switch could use ANY positive/negative value to mean 'true' or (1)-- but that
> doesn't seem to be a correct interpretation. It seems that only #switch(1)
> works.
this isn't about truth, it as simple as "does value A match value B".
> If I could just get past *these* misunderstandings, my world would be a MUCH
> happier place to be in ;-)
I think that if you calculated the value you're interested in beforehand
and then used a variable (only), there'd be much less confusion, for
instance:
#local A = 1;
#switch (A)
#case (1)
#debug concat("one\n")
#break
#case (2)
#debug concat("two\n")
#break
#case (3)
#debug concat("three\n")
#break
#else
#debug concat("oops\n")
#end
now try it with other values for A, 2, etc. hth.
oh, and just to give you a "headache" :-) using the logical not
operator as suggested by Alain? try this (no further savings though):
(!(strcmp(IMG_TYP,AA)&strcmp(IMG_TYP,BB)&strcmp(IMG_TYP,CC)))
;-)
https://en.wikipedia.org/wiki/De_Morgan%27s_laws
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 10.11.2017 um 22:15 schrieb Kenneth:
> My basic question is: When is the #switch() value considered an actual Boolean
> true/false value, vs. a 'simple numerical' value?
Technically, the value in a `#switch` construct is /always/ compared
numerically to those in the `#case` statements. I.e. even if you
explicitly specify `true` anywhere there, it is interpreted as 1, and
will /not/ match any other nonzero value.
>
> Getting back to basics-- e.g., NOT using the strcmp() string-compare function to
> complicate things-- consider the following:
>
> #declare C = 27;
>
> (A)
> This works successfully...
> #switch(1) // Boolean 'true'
> #case(C = 27) // a Boolean comparison that's also 'true'
The comparison operators return "genuine" `true` or `false`, i.e. 1 or 0.
> (B)
> This ALSO works... two 'numerical values' that match
> #switch(27)
> #case(C)
Yup. Of course this works.
> (C)This does NOT work (it falls through to the #else clause)...
> #switch(1000) // or 343 or -89 or any other non-zero value
> #case(C = 27) // the Boolean comparison again
This does not work, because "genuine" `true` = 1 is /not/ equal to 1000.
> If I could just get past *these* misunderstandings, my world would be a MUCH
> happier place to be in ;-)
I'd also like to re-iterate that the above constructs are all
"upside-down" usages of the `#switch` statement. The intentional use is
to specify a variable expression-to-be-examined in the `#switch`
statement itself, and constant expressions-to-match in the `#case` (or
`#range`) statements. E.g.:
#switch(Count)
#case(0)
#debug "None.\n"
#break
#case(1)
#debug "One.\n"
#break
#case(2)
#debug "Two.\n"
#break
#range(3,5)
#debug "Several.\n"
#break
#else
#debug "Plenty.\n"
#break
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
-- mainly because there's a specific stumbling
> block or two that's giving me a problem.
Yes, because you're doing that weird thing with #switch(), which erects the
stumbling block.
> My basic question is: When is the #switch() value considered an actual Boolean
> true/false value, vs. a 'simple numerical' value?
The #switch() value isn't the thing that's the Boolean value.
The result of the comparison of the #case() with the #switch() is.
Imagine that they are all
#if ( #switch(Trigger) = #case(ThisSpecificCase) )
#elseif()
#end
> consider the following:
> #declare C = 27;
> (A)
> This works successfully...
> #switch(1) // Boolean 'true'
> #case(C = 27) // a Boolean comparison that's also 'true'
normally this would be "phrased" as:
#switch (C)
#case (27)
#break
#end
> (B)
> This ALSO works... two 'numerical values' that match
> #switch(27)
> #case(C)
Similar to the above, although an interesting reversal.
I've never thought to do it that way, but it may open up interesting
possibilities... :)
> (C)This does NOT work (it falls through to the #else clause)...
> #switch(1000) // or 343 or -89 or any other non-zero value
> #case(C = 27) // the Boolean comparison again
....or any non-ONE value.
because (C=27) evaluated as a Boolean comparison is true, which results in a
value of 1. And as jr pointed out, 1000 <> 1, or 1000 != 1, however you want
to write it...
> Regarding (A) and (B), it appears that #switch 'changes its operational mode'--
> depending on the particular 'kind' of #case that it's presented with (Boolean
> true/false vs. a simple number.)
Nope. The above examples should disabuse your mind of that fundamentally flawed
concept.
The #switch() value isn't the thing that's the Boolean value.
The _result of the comparison_ of the #case() with the #switch() IS.
> Regarding (C), I was under the impression from some earlier comments that
> #switch could use ANY positive/negative value to mean 'true' or (1)-- but that
> doesn't seem to be a correct interpretation. It seems that only #switch(1)
> works.
I think what was trying to be expressed, was that only zero is interpreted as
Boolean false in SDL, whereas any non-zero value is then by default interpreted
as true, since they're all non-zero.
> If I could just get past *these* misunderstandings, my world would be a MUCH
> happier place to be in ;-)
I hope you're happy.
:P
;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
On 11/11/2017 01:23, Bald Eagle wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> (B)
>> This ALSO works... two 'numerical values' that match
>> #switch(27)
>> #case(C)
> Similar to the above, although an interesting reversal.
> I've never thought to do it that way, but it may open up interesting
> possibilities... :)
thanks for pointing this out, I'd never have occurred to me.
fwiw, I can't think of another language that allows variables as case
"constants". v cool.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > Regarding (A) and (B), it appears that #switch 'changes its operational
> > mode'-- depending on the particular 'kind' of #case that it's presented
> > with (Boolean true/false vs. a simple number.)
>
> Nope. The above examples should disabuse your mind of that fundamentally
> flawed concept.
> The #switch() value isn't the thing that's the Boolean value.
> The _result of the comparison_ of the #case() with the #switch() IS.
Yeah, that seems like an important yet subtle distinction that I'm not making.
Except that it's not-so-subtle, ha. :-[ I do see what you're getting at; I need
to chew on it for awhile so that it sinks in. (Oops, mixed metaphors...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 10.11.2017 um 22:15 schrieb Kenneth:
> > If I could just get past *these* misunderstandings, my world would be a MUCH
> > happier place to be in ;-)
>
>
> I'd also like to re-iterate that the above constructs are all
> "upside-down" usages of the `#switch` statement. The intentional use is
> to specify a variable expression-to-be-examined in the `#switch`
> statement itself, and constant expressions-to-match in the `#case` (or
> `#range`) statements.
Ah, I see! That's actually a revelation to me, and probably my major stumbling
block. I've always thought of #switch/#case in the 'upside-down' mode-- that
the #switch should contain the Boolean 'trigger' of 0 or 1, and the #case
statements should contain the variables-- a configuration that just seems more
natural to me for some reason (although it obviously leads to problems!) And,
my *original* (non-working) example of using #switch(1000) was admittedly out of
desperation, to get it to 'numerically agree/disagree' with
(strcmp(IMG_TYPE,AA) + 1000) and its brothers.
So it looks like even my final *successful* scene example of...
#switch(1)
#case((strcmp(IMG_TYPE,AA)=0)
....etc...
....is also 'upside down'. In fact, it also now looks like quite a 'special
case', because of my use of strings and strcmp() rather than 'typical'
variables. But re-configuring this to be 'right-side-up' looks to be difficult,
*because* of its special-case nature and the many 'string constants' I'm using
(AA,BB,CC etc.) It looks like I actually need the upside-down strategy, for my
particular scene.
I finally got around to reading the Wikipedia article about the #switch
statement-- which has subtle operational differences depending on the
programming language. But I came across this--in 'Alternative Uses', ha...
"...in PHP, a constant can be used as the "variable" to check against, and the
first case statement which evaluates to that constant will be executed. This
feature is also useful for checking multiple variables against one value rather
than one variable against many values."
That looks like part of my (mis-)conception of switch/case's NORMAL operation!
Now I need to re-digest this entire post in light of this 'new' discovery; it's
almost a paradigm shift. :-O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
jr <cre### [at] gmailcom> wrote:
> hi,
>
> On 11/11/2017 01:23, Bald Eagle wrote:
> > "Kenneth" <kdw### [at] gmailcom> wrote:
> >> (B)
> >> This ALSO works... two 'numerical values' that match
> >> #switch(27)
> >> #case(C)
> > Similar to the above, although an interesting reversal.
> > I've never thought to do it that way, but it may open up interesting
> > possibilities... :)
>
> thanks for pointing this out, I'd never have occurred to me.
>
> fwiw, I can't think of another language that allows variables as case
> "constants". v cool.
And I'm beginning to see that this particular example may be the real cause of
my fundamental question about #switch()-- my quasi-misconception of it's
'Boolean behavior' vs. comparison of 'simple numerical values.' Because, it
just so happens that in POV-Ray, #switch/#case can do this. (I probably stumbled
on this behavior by accident, when I first began working with #switch-- and then
took it to be ONE of the two 'typical' modes of operation!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
