x == (y || z)

[Phantom]

I don't understand what your saying about what I said is incorrect.

You said the following:
0 == (1||0) .... = (0==1) = 0. so it gives false

Looking at it again, I see thats actually is infact true, you do understand that || stands for OR correct? If the OR statement was an bit-wsie OR statement then it would be false. But its not and 0==0 is a true statement.

 

[Sep102]

Perhaps this would clarify his statement a bit better

We have:

false == (true || false);

Now, first we evaluate the (true || false):

(true || false) = true

Next we evaluate the rest of the statement, substituting in the first part we evaluated:

false == (true || false) = false == true = false

So, therefore, in his statement he is correct in that it does indeed evaluate to false.

 

[Dipset]

You guys take things a bit to far.

 

[Phantom]

Perhaps this would clarify his statement a bit better

We have:

false == (true || false);

Now, first we evaluate the (true || false):

(true || false) = true

Next we evaluate the rest of the statement, substituting in the first part we evaluated:

false == (true || false) = false == true = false

So, therefore, in his statement he is correct in that it does indeed evaluate to false.

See the problem with your the statement its "false" is beause the statement itself is incorrect. Your doing an operation that is illegal in a sense. Taking the statement into context, what the real value is, is what the correct statement would do.

I am still going to say your incorrect for saying its false.

 

[Ravatar]

	switch(x)
	{
		case y:
		case z:
		{
		
		} break;
	}

 

[yarex]

I am still going to say your incorrect for saying its false.

To end this academic debate:

First statement was: x == (y || z)
They wanted to replace it with: x == y || x == z

I say that it's incorrect, becouse these two statements are mathe,atically inequal, and in some conditions they give different results.

The correct mathematical replacement is this: (x & (y || z)) || (!x & (!y & !z))


Here is the proof - binary table for all cases.

x y z x == (y || z) x == y || x == z x & (y || z)] || [!x & (!y & !z)
0 0 0 1 1 1
0 1 0 0 1 0
0 0 1 0 1 0
0 1 1 0 0 0
1 0 0 0 0 0
1 1 0 1 1 1
1 0 1 1 1 1
1 1 1 1 1 1

So, as you can see, in case of 0|1|1 or 1|0|0 x==y||x==z gives incorrect result, and that is the thing that i originally wanted to point out.


Here is the c# script to test all cases:

(replace x,y,z with true|false as required)

using System;

namespace Test
{
public class MainApp
{
public static void Main()
{
bool x = true;
bool y = true;
bool z = true;

Console.WriteLine(x == (y || z));
Console.WriteLine(x == y || x == z);
Console.WriteLine((x & (y || z)) || (!x & (!y & !z)));

Console.WriteLine("--ende--");
Console.Read();
}
}
}

 

[arul]

...snip...

The problem here is that Dipset doesnt want to compare boolean expression but object references, which is not possible because logical OR '||' needs a logical value on both sides.

I also noticed small mistake in your code

Console.WriteLine((x [B]&[/B] (y || z)) || (!x [B]&[/B] (!y [B]&[/B] !z)));

Those should be logical AND '&&' and not bitwise AND '&'.

Back to the topic...
For comparation like X==(y||z ... ||n) you could use following method but it obvoiusly has its flaws on the preformance.

public static bool RefsEquals ( object o, params object[] objs )
{
     for ( int i = 0; i < objs.Length; i++ )
     {
          if ( o == objs[i] ) { return(true); } 
     }
 
     return(false);
}

And then you can call the method like this

if ( RefsEquals ( x, y, z ) )
....

 

[Sep102]

I also noticed small mistake in your code

Console.WriteLine((x [B]&[/B] (y || z)) || (!x [B]&[/B] (!y [B]&[/B] !z)));

Those should be logical AND '&&' and not binary AND '&'.

A couple of notes, first, (at least in this usage) both '&&' and '&' are binary AND's, i.e. they take two operands each. The correct term for the usage of '&' that you're looking for is bitwise AND. Second, '&' performs the same operation as '&&' (sans short-circuit evaluation) when applied to bool values, of course, it's still actually computing the bitwise AND when applying it to bool values, but, due to the fact that there are only two values possible, it becomes the same operation as a logical AND. See MSDN for further details.

 

[arul]

A couple of notes, first, (at least in this usage) both '&&' and '&' are binary AND's, i.e. they take two operands each. The correct term for the usage of '&' that you're looking for is bitwise AND

yeah, I meant 'bitwise', thanks for the catch.

Second, '&' performs the same operation as '&&' (sans short-circuit evaluation) when applied to bool values, it only performs a bitwise AND when applied to operands of integral type. See MSDN for further details.

Sure thing, but obfuscating bitwise and logical operators is at least bad habit and significantly degrades readability of code.

 

[Sep102]

Sure thing, but obfuscating bitwise and logical operators is at least bad habit and significantly degrades readability of code.

Oh, don't get me wrong, I wasn't disagreeing with you for pointing that out, just adding the fact that in that situation they both have the same semantics. I even asserted a point much like this one in my last post in this thread (which, by the way, is what I remember this from), so I do agree fully with your opinion on the matter.