how do i simplify this expression?

[cHeeZeFacTory]

if ( A==B || A==C || A==D)
...
endif

 

[Ken g6]

Define "simplify". Looks pretty darn simple to me. But what are A, B, C, and D; how are they compared?

 

[cHeeZeFacTory]

A,B,C,D are just variables. lets say they're strings.

 

[BoberFett]

if ( A==B || A==C || A==D)
...
endif

How much simpler can it get? Are you concerned about performance? Are you worried about evaluating three different huge string variables every time this happens?

You could throw it in a function:

if CompareVars(a,b,c,d) = 1 then
    ...
end if

function CompareVars(a, b, c, d)
    if a <> b return 0
    if a <> c return 0
    if a <> d return 0
    return 1
end function

Without more details, you can't much simpler than an IF. What are the specific reasons you're trying to optimize such a small bit of code?

 

[tatteredpotato]

Are you looking for some sort of boolean factoring technique like (A== (B||C||D))? Because no programming language I know works that way (and it really wouldn't make sense to).

 

[Cogman]

Well, something like this would be slightly faster

if (A == B | A == C | A == D)
do stuff.

It takes advantage of the fact that bitwise operators are faster than logical operators. Since, A==B always equals 1 or 0 this is valid. However, something like if (A | B) could possibly produce some invalid result.

 

[IHateMyJob2004]

Cogman,

What language. I'd think that he java JVM would optimize this at runtime to do what you said.

All you can really do is put the likelihood of failure in order. This is compiler dependent for C/C++ but the Java spec says left to right processing order.

So, for Java, you would put the expression most likely to fail first and least likely last. This way, the case where the expression returns false is calculated in the fastest average time.

This is a micro-optimization though. In the real world, it is not worth the time it takes to think about it.

 

[bobross419]

Could someone explain the difference between OP and Cogman's code... All I see is that Cogman removed three of the pipes.

 

[Cogman]

Cogman,

What language. I'd think that he java JVM would optimize this at runtime to do what you said.

All you can really do is put the likelihood of failure in order. This is compiler dependent for C/C++ but the Java spec says left to right processing order.

So, for Java, you would put the expression most likely to fail first and least likely last. This way, the case where the expression returns false is calculated in the fastest average time.

This is a micro-optimization though. In the real world, it is not worth the time it takes to think about it.

I was assuming C/C++. It is an interesting setup because most compilers actually won't catch this optimization. I really don't think that the JVM would be any different. They don't catch it because it is actually different. Sort of like using the "restrict" keyword in C++.

 

[Cogman]

Could someone explain the difference between OP and Cogman's code... All I see is that Cogman removed three of the pipes.

Assuming a C/C++ like language, My code uses bitwise ors, the OPs uses logical ors. That means that mine instructs the compiler to just or the results of each equality together while to ops tells the compiler that it must first find the logical equivalent of the results of the equalities before taking the bitwise or. In other words, it has to convert a non 1/0 value into a 1/0 value. (even though the equalities are only capable of returning a 1/0 value).

 

[Ken g6]

Could someone explain the difference between OP and Cogman's code... All I see is that Cogman removed three of the pipes.

Assuming a C/C++ like language, My code uses bitwise ors, the OPs uses logical ors. That means that mine instructs the compiler to just or the results of each equality together while to ops tells the compiler that it must first find the logical equivalent of the results of the equalities before taking the bitwise or. In other words, it has to convert a non 1/0 value into a 1/0 value. (even though the equalities are only capable of returning a 1/0 value).

There's another difference. When testing (x|y|z), all the results have to be computed and or-ed together. When testing (x||y||z), if x is true, y and z don't matter, and so they may not be touched at all. In general with C-like languages:

if ( A==B || A==C || A==D)
...
endif

is equivalent to

if( A==B ) goto doit;
if( A==C ) goto doit;
if( A==D ) goto doit;
goto dontdoit;
:doit
...
:dontdoit

 

[bobross419]

Cool, thanks

 

[tatteredpotato]

There's another difference. When testing (x|y|z), all the results have to be computed and or-ed together. When testing (x||y||z), if x is true, y and z don't matter, and so they may not be touched at all. In general with C-like languages:

if ( A==B || A==C || A==D)
...
endif

is equivalent to

if( A==B ) goto doit;
if( A==C ) goto doit;
if( A==D ) goto doit;
goto dontdoit;
:doit
...
:dontdoit

In my compilers course we elaborate (a||b) and (a&&b) to (a ? true : b) and (a ? b : false), which I think is somewhat common practice. That representation also performs the short-circuit evaluation.

 

[BoberFett]

There's another difference. When testing (x|y|z), all the results have to be computed and or-ed together. When testing (x||y||z), if x is true, y and z don't matter, and so they may not be touched at all. In general with C-like languages:

if ( A==B || A==C || A==D)
...
endif

is equivalent to

if( A==B ) goto doit;
if( A==C ) goto doit;
if( A==D ) goto doit;
goto dontdoit;
:doit
...
:dontdoit

Yeah, depends on the language. A smart compiler would do it that way, but some interpreted languages will evaluate every expression.

 

[Woosta]

>>> a=b=c=d=2
>>> a in [b,c,d]
True
>>> a = 1
>>> a in [b,c,d]
False

Python offers the IN operator.