POV-Ray : Newsgroups : povray.advanced-users : problem using ORs and strcmp() in #switch/#case Server Time
16 May 2024 00:24:06 EDT (-0400)
  problem using ORs and strcmp() in #switch/#case (Message 31 to 36 of 36)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: clipka
Subject: Re: problem using ORs and strcmp() in #switch/#case
Date: 10 Nov 2017 20:01:48
Message: <5a064bfc$1@news.povray.org>
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

From: Bald Eagle
Subject: Re: problem using ORs and strcmp() in #switch/#case
Date: 10 Nov 2017 20:25:01
Message: <web.5a0651081346e9e05cafe28e0@news.povray.org>
"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

From: jr
Subject: Re: problem using ORs and strcmp() in #switch/#case
Date: 11 Nov 2017 07:43:17
Message: <5a06f065$1@news.povray.org>
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

From: Kenneth
Subject: Re: problem using ORs and strcmp() in #switch/#case
Date: 11 Nov 2017 13:35:00
Message: <web.5a0742711346e9e089df8d30@news.povray.org>
"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

From: Kenneth
Subject: Re: problem using ORs and strcmp() in #switch/#case
Date: 11 Nov 2017 13:55:01
Message: <web.5a0746151346e9e089df8d30@news.povray.org>
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

From: Kenneth
Subject: Re: problem using ORs and strcmp() in #switch/#case
Date: 11 Nov 2017 14:25:00
Message: <web.5a074d5a1346e9e089df8d30@news.povray.org>
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

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.