I'm having  a subtle problem that I can't pin down, when trying to use
logical-OR statements inside of #case directives. I'm using the strcmp()
function to compare various strings, plus OR blocks separating those strcmp()
comparisons inside of each #case. Posting my problematic scene code isn't
practical here (it involves lots of image_maps), but I came up with a simplified
test. I'm hoping to glean some insights into these interactions, from more
astute newsgroup observers ;-)

There are four things involved: strings, #switch/#case, the strcmp() function,
and OR.

Here's the test code, before I go into the details. Note that IMG_TYPE and AA
exactly match. The problem is that #switch is falling through to the #else
clause, when it should not do so (because  IMG_TYPE and AA *are* the same.)  If
the #case clause is successful, you'll see a GREEN box; otherwise, a
crosshatched box.  Comment-out the two OR lines for a successful test.
--------------------
#version 3.71; // or 3.7

global_settings{assumed_gamma 1.0 max_trace_level 5}
default{finish{ambient 0 emission 1 diffuse 0}}

camera {
  perspective
  location  <.5, .5, -1.5>
  look_at   <.5, .5, 0>
}

#declare IMG_TYPE = "jpg"
#local AA = "jpg"
#local BB = "png"
#local CC = "tiff"

box{0,<1,1,0>
no_shadow
pigment{
    #switch(1000)
    #case(
    // INDIVIDUALLY, these all work the way they are supposed to-- but not
    // all three at once. The OR's are causing some kind of problem, and
    // the result always fall through to the #else clause.
        (strcmp(IMG_TYPE,AA) + 1000)
        | (strcmp(IMG_TYPE,BB) + 1000)
        | (strcmp(IMG_TYPE,CC) + 1000)
         )
    srgb <0,1,0> // GREEN square
    #debug "\nAt least ONE of the #case clauses is valid.\n\n\n\n"
    #break
    #else
    // A cross-hatch warning image...
    average
    pigment_map{
         [1 gradient x+y
              frequency 6
              color_map{
                  [.25 srgb <1,0,0>]
                  [.25 srgb 0]
                        }
         ]
         [1 gradient x-y
              frequency 6
              color_map{
                  [.25 srgb <1,0,0>]
                  [.25 srgb 0]
                       }
         ]
                }
     #debug "\nNO #case clause is valid.\n\n"
     #end // of #switch
        } // end of pigment
    }
 -----------------------

I assume that a #case clause can USE logical operators like ORs??

What DOES work is to *remove* all of the OR blocks--using just ONE
strcmp() + 1000   in the #case (any one of the three). That results in correct
#switch behavior (either a 'go' of 'no go'.) That's not what I want, of course,
as I need all three in the #case statement. But is it possible that OR is not
the correct logical operator to use? One *guess* I have is that  #case is
'reading' the   strcmp()-plus-OR blocks    left to right-- and finally comes to
strcmp(IMG_TYPE,CC) + 1000,  the result of which does NOT 'match'
#switch(1000)  ... possibly causing the fall-through to the #else clause(?)

My understanding of #switch is that ANY value can be used; it doesn't
specifically need just TRUE/FALSE of 1/0, just so long as a particular #case
result matches it.  But I don't really know its hidden operation. BTW,  I didn't
use 'TRUE' in the #switch() because, when strcmp() finds two strings that
*match*, its numerical output is zero-- which should  be a logical 'false' in a
TRUE/FALSE clause, not 'true.' (AFAIU!)

Perhaps I shouldn't be using strcmp() at all. It *is* a rather complex beast--
its numerical output depends on where the various strings fall into the 'ASCII
collating sequence.' (I had to re-read the docs to try and understand this,
along with running some experiments.) My use of  +1000  in the #switch clause
(and in the #case arguments) was to try and avoid such problems, as 1000 is way
outside of the ASCII numbering sequence. But no matter *what* numerical value I
use-- while also using the ORs-- the #else clause is always invoked.

And in my real scene, I'm finding that the OR clauses *sometimes* need the added
parentheses around  the various    strcmp() + 1000   statements -- but that
seems to work inconsistently as well  :-/

Post a reply to this message