how to simplify many OR in if statement?

[Alan]

I have many OR in the if statement, any method to simplify?

if (val == 5 | val == 9 | val == 34 | val == 111 | val == 131 | .......)
// ....

thank you

 

[Robert Stankowic]

I have many OR in the if statement, any method to simplify?

if (val == 5 | val == 9 | val == 34 | val == 111 | val == 131 | .......)
// ....

ITYM
if(val == 5 || val == 9......

If there is no systematic in the values of val, the only thing I can think
of is a switch:

switch(val)
{
case 5:
case 9:
case 34:
....
case 234:
<do your stuff here>
break;
}

But I'd rethink the approach if it requires such a mass of or's

Robert

 

[Jeff Schwab]

I have many OR in the if statement, any method to simplify?

if (val == 5 | val == 9 | val == 34 | val == 111 | val == 131 | .......)
// ....

thank you

Please don't cross-post.

I assume you want to be able to do something like this:

int main( )
{
int var = 3; // Initialize to whatever...

if( in_set( var ) )
{
// ...
}
}

The long "or" statement is not a bad way to go, unless you have a
really, really large set of numbers to check. Here is a couple of
alternatives:

/* C or C++ */

int in_set( int i )
{
int result = 0;

switch( i )
{
case 5:
case 9:
case 34:
case 111:
case 131:
result = 1;
}

return result;
}


/* C++ only */

namespace
{
int values[ ] = { 5, 9, 34, 111, 131 /* , ... */ };
int num_values = sizeof values / sizeof *values;

std::set< int > value_set( values, values + num_values );

inline bool in_set( int i )
{
return value_set.find( i ) != value_set.end( );
}
}

 

[Mike Hewson]

I have many OR in the if statement, any method to simplify?

if (val == 5 | val == 9 | val == 34 | val == 111 | val == 131 | .......)
// ....

Don't know of any evident simplification, assuming the logic of the
problem actually *requires* some common code to be executed for those many
different values of 'val'.

One can *restate* using De Morgan's theorem:

if( !(val <> 5 && val <> 9 && val <> 34 && val <> 111 && val <> 131 &&
........) )
// Common code.

which flicks the OR's, but alas no more simply!

You could create a boolean array, and use val as an index for it, with
the array elements indicating a 'yes' for 5,9,34,111,131...... ( and 'no'
otherwise ).

if( boolean_array[val] == true )
// Common code.

but then one also needs memory for the array, and some initialization of
it's contents to boot.

What is the context of your logical expression?

 

[Christopher Benson-Manica]

Please don't cross-post.

You mean "Please cross-post carefully." comp.lang.c++ was clearly not
warranted, but there's nothing wrong with this going to acllcc++...

switch( i )
{
case 5:
case 9:
case 34:
case 111:
case 131:
result = 1;
}

I rather prefer this method myself, FWIW.

 

[Ron Natalie]

if( !(val <> 5 && val <> 9 && val <> 34 && val <> 111 && val <> 131 &&

And what language is this? Looks like some mutant cross between C++ and Fortran.

 

[Cy Edmunds]

&&

And what language is this? Looks like some mutant cross between C++ and Fortran.

It's that De Morgan guy. Couldn't program his way out of a paper bag.

 

[Jeff Schwab]

You mean "Please cross-post carefully." comp.lang.c++ was clearly not
warranted, but there's nothing wrong with this going to acllcc++...

Right you are!

I rather prefer this method myself, FWIW.

I would like this if I knew a suitable jump-table would be generated in
the code, but for such disparate values... Anyway, I actually *did*
like Mike's suggestion of creating an array of boolean values:

if( boolean_array[val] == true )
// Common code.


-Jefff

 

[Keith Thompson]

I would like this if I knew a suitable jump-table would be generated
in the code, but for such disparate values... Anyway, I actually
*did* like Mike's suggestion of creating an array of boolean values:

if( boolean_array[val] == true )
// Common code.

Even assuming you have an appropriate definition for "true", the
comparison is unnecesary. In general, explicitly comparing boolean
values to "true" or "false" is unnecessary and potentially dangerous.
It's already a boolean, after all.

C (unless you have C99) has no predefined boolean type. In both C and
C++, any non-zero integer value is considered true in a condition; if
your "true" is defined as 1, the comparison will fail for any value
other than 0 or 1.

Just use

if ( boolean_array[val] ) {
/* blah blah */
}

(If you think that "boolean_array[val] == true" is clearer, you should
think that "(boolean_array[val] == true) == true" is even clearer.)

Note that this argument doesn't apply to non-boolean values used as
conditions. A pointer value, for example, can be used as a condition
(implicitly testing whether it's a null pointer), but many programmers
prefer to make the comparison explicit; "if (p)" and "if (p != NULL)"
are equally valid.

 

[Jeff Schwab]

I would like this if I knew a suitable jump-table would be generated
in the code, but for such disparate values... Anyway, I actually
*did* like Mike's suggestion of creating an array of boolean values:

if( boolean_array[val] == true )
// Common code.

Even assuming you have an appropriate definition for "true", the
comparison is unnecesary. In general, explicitly comparing boolean
values to "true" or "false" is unnecessary and potentially dangerous.
It's already a boolean, after all.

I agree completely; I was copying someone Mike's code. Anyway, I see
nothing inherently wrong with "== true," even though I prefer to skip it.

Note that this argument doesn't apply to non-boolean values used as
conditions. A pointer value, for example, can be used as a condition
(implicitly testing whether it's a null pointer), but many programmers
prefer to make the comparison explicit; "if (p)" and "if (p != NULL)"
are equally valid.

That's exactly the same situation. I also prefer "if( p )" to "if p !=
NULL )," but I see no need to be religious about it. The one that
really bugs me is seeing someone "correct" this:

if( p == NULL )

to this:

if( NULL == p )

This is supposed to help avoid accidental assignment in the test.
However, I think "if( p )" avoids the same problem in a much shorter,
more readable way.

Anway, different key-strokes for different folks, I guess.

-Jeff

 

[John Bode]

I have many OR in the if statement, any method to simplify?

if (val == 5 | val == 9 | val == 34 | val == 111 | val == 131 | .......)
// ....

thank you

First of all, I think you want the logical OR operator || instead of
the bitwise OR operator |. Other than that...

Personally, I would put this test into its own function.

#ifndef TRUE
#define TRUE (1)
#define FALSE (0)
#endif
...
int valueInSet (int val, int *set, int setsize)
{
int i;

for (i = 0; i < setsize; i++)
{
if (val == set)
return TRUE;
}

return FALSE;
}

int main (void)
{
int testSet[] = {5, 9, 34, 111, 131, ...};
int setSize = (int) (sizeof testSet / sizeof testSet[0]);
int val;
...
if (valueInSet (val, testSet, setSize))
{
/* do something */
}
...
return 0;
}

Yes, it introduces a bit more overhead than just writing out the test
longhand (either using the sequential OR approach or by using the
switch structure others have suggested). The tradeoff is that this
solution is more general. If your test set changes, you don't have to
actually muck with the program logic, just the contents of the test
set.

With some time I could probably come up with something a bit more
clever, but I think this is a good solution.

 

[Robert Bachmann]

And what language is this? Looks like some mutant cross between C++ and Fortran.

C mixed up with Pascal, Basic or some other language which uses <> for
the inequality operator.

It should be rather:
if( !(val != 5 && val != 9 && val != 34 && val != 111 &&/*etc*/

 

[Christian Bau]

I have many OR in the if statement, any method to simplify?

if (val == 5 | val == 9 | val == 34 | val == 111 | val == 131 | .......)

Have a look at the || operator.

 

[Mike Hewson]

&&

And what language is this? Looks like some mutant cross between C++ and

Fortran.

Whoops, my brain fart, sorry!
I was doing VBScripting at the time, and slipped a cog reloading the old
task state segment.
( grumble ..Damned multitasking....grumble ).

Happy to have amused you all, though

 

[Mike Hewson]

I would like this if I knew a suitable jump-table would be generated
in the code, but for such disparate values... Anyway, I actually
*did* like Mike's suggestion of creating an array of boolean values:

if( boolean_array[val] == true )
// Common code.

Even assuming you have an appropriate definition for "true", the
comparison is unnecesary.

Sorry ( again ), I meant to write 'yes' - meaning whatever one had coded in
the array as being that.

In general, explicitly comparing boolean values to "true" or "false" is

unnecessary and potentially > dangerous.

Indeed, please tell.....

 

[Keith Thompson]

I would like this if I knew a suitable jump-table would be generated
in the code, but for such disparate values... Anyway, I actually
*did* like Mike's suggestion of creating an array of boolean values:

if( boolean_array[val] == true )
// Common code.

Even assuming you have an appropriate definition for "true", the
comparison is unnecesary. In general, explicitly comparing boolean
values to "true" or "false" is unnecessary and potentially dangerous.
It's already a boolean, after all.

I agree completely; I was copying someone Mike's code. Anyway, I see
nothing inherently wrong with "== true," even though I prefer to skip
it.

Any non-zero value is considered true. Assuming that "true" is
defined as 1, and "b" has the value 2, the condition (b) is true, but
(b == true) is false.

Even if you're working in a language like C99 or C++ that has an
actual boolean type, there are still a lot of legacy functions that
return integer values, such as the is* functions in <ctype.h>.
There's no requirement that isalpha(), for example, has to return
either 0 or 1.

 

[Mike Hewson]

I would like this if I knew a suitable jump-table would be generated in
the code, but for such disparate values... Anyway, I actually *did*
like Mike's suggestion of creating an array of boolean values:

if( boolean_array[val] == true )
// Common code.

After I posted, I saw yours and liked it better!
A question is, I guess, what is the number of 'hits' you want in the
test compared to the range of possible values of 'val' ( it's type, but be
careful here ). If it's 5 out of 65536 I'm wasting alot array, so better to
just keep a list of the hits as per Jeff.

To the OP, please dive in any time here and let us know what the context
of the test is!

 

[Christian Bau]

[...]
I would like this if I knew a suitable jump-table would be generated
in the code, but for such disparate values... Anyway, I actually
*did* like Mike's suggestion of creating an array of boolean values:

if( boolean_array[val] == true )
// Common code.
Even assuming you have an appropriate definition for "true", the
comparison is unnecesary. In general, explicitly comparing boolean
values to "true" or "false" is unnecessary and potentially dangerous.
It's already a boolean, after all.

I agree completely; I was copying someone Mike's code. Anyway, I see
nothing inherently wrong with "== true," even though I prefer to skip
it.

Any non-zero value is considered true. Assuming that "true" is
defined as 1, and "b" has the value 2, the condition (b) is true, but
(b == true) is false.

Even if you're working in a language like C99 or C++ that has an
actual boolean type, there are still a lot of legacy functions that
return integer values, such as the is* functions in <ctype.h>.
There's no requirement that isalpha(), for example, has to return
either 0 or 1.

The worst case is debugging: You have a program, and you know (by
testing) that under certain circumstances it produces the wrong results.
So you look at code to find which bits of code look like they could go
wrong. In that situation, when you spot

if( boolean_array[val] == true ) ...

you will have to check that "true" is equal to 1 and that the values
stored in boolean_array are always either 0 to 1. If you write

if( boolean_array[val] )

you can save your time. (Note that I expect code to be written by
reasonably competent programmers, and a reasonably competent programmer
would only compare a "boolean" value to true if there are possibilities
other than 0 or 1. As a result, either the comparison "== true" will be
removed after a lengthy check of surrounding code, or a comment will be
added that values other than 0 or 1 are expected).

 

[Bob Summers]

Bob S

I would like this if I knew a suitable jump-table would be generated
in the code, but for such disparate values... Anyway, I actually
*did* like Mike's suggestion of creating an array of boolean values:

if( boolean_array[val] == true )
// Common code.

Even assuming you have an appropriate definition for "true", the
comparison is unnecesary. In general, explicitly comparing boolean
values to "true" or "false" is unnecessary and potentially dangerous.
It's already a boolean, after all.

C (unless you have C99) has no predefined boolean type. In both C and
C++, any non-zero integer value is considered true in a condition; if
your "true" is defined as 1, the comparison will fail for any value
other than 0 or 1.

Just use

if ( boolean_array[val] ) {
/* blah blah */
}

(If you think that "boolean_array[val] == true" is clearer, you should
think that "(boolean_array[val] == true) == true" is even clearer.)

Note that this argument doesn't apply to non-boolean values used as
conditions. A pointer value, for example, can be used as a condition
(implicitly testing whether it's a null pointer), but many programmers
prefer to make the comparison explicit; "if (p)" and "if (p != NULL)"
are equally valid.

--
Keith Thompson (The_Other_Keith) (e-mail address removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

Even if you ignore the possibility that boolean_array[val] has a
non-false value other than true, the use of "x == true" bugs me
because when you use "==" to compare booleans it becomes
an operator that I've seen called "iff" and
"xnor" (exclusive not or) operator.

A B A xnor B
T T T
T F F
F T F
F F T

Why use an obscure boolean operator without a good reason?

I agree with Jeff that an array of boolean values (perhaps a
bit vector) indexed by the value being tested is a little
better than a switch statement. With the array you can pretty well
predict what code will be generated by the compiler. With
a switch statement you don't know. Of course if the code
isn't critical or the number of values you're searching
through is small it doesn't really matter which of the three
techniques you use.

I did work on one memorable program that had an if statement
that was doing this sort of test. The condition portion of
the if statement literally took an entire page of blue bar
(60 lines by 80 characters) even though it was formatted
to use the minimum number of characters. White space?
Doesn't the compiler just ignore it anyway?

If the number of values that you are searching for is large,
then or'ing together a lot of tests is not a good idea. At
that point it becomes a hard-coded sequential search. Actually,
ORing more than about 4 or 5 values is pretty cleary
just a hard-coded sequential search.

Bob S

 

[Gene Wirchenko]

On 23 Dec 2003 20:13:53 EST, (e-mail address removed) (Bob
Summers) wrote:

[snip]

Even if you ignore the possibility that boolean_array[val] has a
non-false value other than true, the use of "x == true" bugs me
because when you use "==" to compare booleans it becomes
an operator that I've seen called "iff" and
"xnor" (exclusive not or) operator.

A B A xnor B
T T T
T F F
F T F
F F T

Why use an obscure boolean operator without a good reason?

Why use any operator without a good reason?

This is not obscure though. It is the equivalence operator, the
boolean equivalent of ==. In logic texts, it has its own symbol of a
two-headed arrow.

[snip]

Sincerely,

Gene Wirchenko