Em seg., 3 de ago. de 2020 às 04:02, Sjoerd Mullender escreveu:

Either way is correct.

Are we missing something? The first form evaluates both (b->ttype != TYPE_void) and b->tkey, both

of which result in either 0 or 1. The single & does a bit-wise AND on those two values and results in 1 if both sides evaluated to 1.

In the second form, if first part evaluates to 0, b->tkey is not

evaluated, and if the first part evaluates to 1, the second part is also evaluated. The restult, again, is only 1 if both sides evaluate to 1.

Wait, bitwse AND (&) is not shortcut, If first part evaluates to 0 *b->key is stiil evaluated.* It is never good to mix relational operators with bitwise operators. regards, Ranier Vilela

Em seg., 3 de ago. de 2020 às 12:50, Sjoerd Mullender escreveu:

On 03/08/2020 15.43, Ranier Vilela wrote:

...

Em seg., 3 de ago. de 2020 às 04:02, Sjoerd Mullender mailto:sjoerd@monetdb.org> escreveu:

Either way is correct.

Are we missing something?

The first form evaluates both (b->ttype != TYPE_void) and b->tkey, both of which result in either 0 or 1. The single & does a bit-wise AND on those two values and results in 1 if both sides evaluated to 1.

In the second form, if first part evaluates to 0, b->tkey is not evaluated,

Sorry, see: " In the second form, if first part evaluates to 0, b->tkey is not evaluated," No matter the outcome of the first part, b-> key will always be evaluated. and if the first part evaluates to 1, the second part is also

...

evaluated. The restult, again, is only 1 if both sides evaluate to

1.

...

Wait, bitwse AND (&) is not shortcut, If first part evaluates to 0 *b->key is stiil evaluated.*

That's correct. I think I mentioned that.

Sorry, but I think it contradicts your first email, you say "not evaluated". regards, Ranier Vilela

Em seg., 3 de ago. de 2020 às 13:22, Sjoerd Mullender escreveu:

On 03/08/2020 17.55, Ranier Vilela wrote:

...

Em seg., 3 de ago. de 2020 às 12:50, Sjoerd Mullender mailto:sjoerd@monetdb.org> escreveu:

On 03/08/2020 15.43, Ranier Vilela wrote: > Em seg., 3 de ago. de 2020 às 04:02, Sjoerd Mullender > mailto:sjoerd@monetdb.org mailto:sjoerd@monetdb.org>> escreveu: > > Either way is correct. > > Are we missing something? > > The first form evaluates both (b->ttype != TYPE_void) and b->tkey, both > of which result in either 0 or 1. The single & does a bit-wise AND on > those two values and results in 1 if both sides evaluated to 1. > > In the second form, if first part evaluates to 0, b->tkey is not > evaluated,

Sorry, see: " In the second form, if first part evaluates to 0, b->tkey is not evaluated," No matter the outcome of the first part, b-> key will always be evaluated.

and if the first part evaluates to 1, the second part is also > evaluated. The restult, again, is only 1 if both sides evaluate to 1. > > Wait, bitwse AND (&) is not shortcut, If first part evaluates to 0 > *b->key is stiil evaluated.*

That's correct. I think I mentioned that.

Sorry, but I think it contradicts your first email, you say "not evaluated".

I wrote (and I copy/paste): "The first form evaluates both (b->ttype != TYPE_void) and b->tkey" and "In the second form, if first part evaluates to 0, b->tkey is not evaluated"

The first form being the one with the bitwise &, the second form being the one with the logical &&.

In any case, with & both sides are always evaluated and there is no shortcut. With && if the left side evaluates to 0, the right side is not evaluated. The thing is, in order to skip evaluation, a jump is needed over the code that does the evaluation. Conditional jumps may be expensive. So it may be faster to evaluate both sides (and not jump) than to skip evaluation of one side at the cost of a conditional jump. (It's the conditionality that makes it potentially expensive.)

I agree with you about trick to gain performance. But this: if (b->ttype != TYPE_void) & b->tkey) Is the same write: if (b->key) And if is correct, was that the original intention? See: int main () { bool r = true; bool key = true; const char * ptr = "not null"; void * pvoid = NULL; r = (ptr == pvoid); if (r) printf("true\n"); else printf("false\n"); r = ((ptr == pvoid) & key); if (r) printf("true"); else printf("false"); return 0; } Here do not matters key value, always be output is false, be key true or false. See: https://www.gamedev.net/forums/topic/514727-combining-c-bool-and-bitwise-ope... regards, Ranier Vilela

On 03/08/2020 18.29, Ranier Vilela wrote:

Em seg., 3 de ago. de 2020 às 13:22, Sjoerd Mullender mailto:sjoerd@monetdb.org> escreveu:

On 03/08/2020 17.55, Ranier Vilela wrote: > Em seg., 3 de ago. de 2020 às 12:50, Sjoerd Mullender > mailto:sjoerd@monetdb.org mailto:sjoerd@monetdb.org>> escreveu: > > > >     On 03/08/2020 15.43, Ranier Vilela wrote: >     > Em seg., 3 de ago. de 2020 às 04:02, Sjoerd Mullender >     > mailto:sjoerd@monetdb.org mailto:sjoerd@monetdb.org> >     mailto:sjoerd@monetdb.org mailto:sjoerd@monetdb.org>>> escreveu: >     > >     >     Either way is correct. >     > >     > Are we missing something? >     > >     >     The first form evaluates both (b->ttype != TYPE_void) and >     b->tkey, both >     >     of which result in either 0 or 1.  The single & does a >     bit-wise AND on >     >     those two values and results in 1 if both sides evaluated to 1. >     > >     >     In the second form, if first part evaluates to 0, b->tkey is not >     >     evaluated, > > Sorry, see: >  " In the second form, if first part evaluates to 0, b->tkey is not > evaluated," > No matter the outcome of the first part, b-> key will always be evaluated. > >     and if the first part evaluates to 1, the second part is also >     >     evaluated.  The restult, again, is only 1 if both sides >     evaluate to 1. >     > >     > Wait, bitwse AND (&) is not shortcut, If first part evaluates to 0 >     > *b->key is stiil evaluated.* > >     That's correct.  I think I mentioned that. > > Sorry, but I think it contradicts your first email, you say "not > evaluated".

I wrote (and I copy/paste): "The first form evaluates both (b->ttype != TYPE_void) and b->tkey" and "In the second form, if first part evaluates to 0, b->tkey is not evaluated"

The first form being the one with the bitwise &, the second form being the one with the logical &&.

In any case, with & both sides are always evaluated and there is no shortcut.  With && if the left side evaluates to 0, the right side is not evaluated. The thing is, in order to skip evaluation, a jump is needed over the code that does the evaluation.  Conditional jumps may be expensive.  So it may be faster to evaluate both sides (and not jump) than to skip evaluation of one side at the cost of a conditional jump.  (It's the conditionality that makes it potentially expensive.)

I agree with you about trick to gain performance.

But this: if (b->ttype != TYPE_void) & b->tkey)

Is the same write: if (b->key)

And if is correct, was that the original intention?

No it is not the same. Look at the four possibities. Either (b->ttype != TYPE_void) is either 0 or 1, and b->tkey likewise is either 0 (false) or 1 (true). The four possibilities therefore are 0&0, 0&1, 1&0, 1&1. The results are thus 0 0 0 1 In other words, only if the first part evaluates to 1 is the result equal to the value of b->tkey, but if the first part evaluates to 0, the result is 0, no matter the value of b->tkey.

See: int main () {     bool r = true;     bool key = true;     const char * ptr = "not null";     void * pvoid = NULL;

    r = (ptr == pvoid);     if (r)        printf("true\n");     else        printf("false\n");

    r = ((ptr == pvoid) & key);     if (r)        printf("true");     else        printf("false");     return 0; }

Here do not matters key value, always be output is false, be key true or false.

See: https://www.gamedev.net/forums/topic/514727-combining-c-bool-and-bitwise-ope...

regards, Ranier Vilela

_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list

-- Sjoerd Mullender

Sjoerd, Nice explanation, so if they are both correct and one avoids unnecessary work (even just a tiny bit) why not adjust the code to add your explanation as a comment and use the more efficient version? -greg On Mon, Aug 3, 2020 at 3:02 AM Sjoerd Mullender wrote:

Either way is correct. The first form evaluates both (b->ttype != TYPE_void) and b->tkey, both of which result in either 0 or 1. The single & does a bit-wise AND on those two values and results in 1 if both sides evaluated to 1. In the second form, if first part evaluates to 0, b->tkey is not evaluated, and if the first part evaluates to 1, the second part is also evaluated. The restult, again, is only 1 if both sides evaluate to 1.

So the difference is whether or not b->tkey is evaluated, and evaluating that is cheap (it's a bool value).

On 01/08/2020 20.54, Ranier Vilela wrote:

...

Hi,

At gdk\gdk_bat.c (line 1384) variable b->type is bool

Would be a typo? if (((b->ttype != TYPE_void) & b->tkey) && b->batCount > 1) { Should be: if (((b->ttype != TYPE_void) && b->tkey) && b->batCount > 1) {

regards, Ranier Vilela

_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list

-- Sjoerd Mullender _______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list

Hi Ranier, On 8/3/20 4:59 PM, Ranier Vilela wrote:

Em seg., 3 de ago. de 2020 às 10:53, Gregory Burd escreveu:

...

Sjoerd,

Nice explanation, so if they are both correct and one avoids unnecessary work (even just a tiny bit) why not adjust the code to add your explanation as a comment and use the more efficient version?

I'm not sure that is correct. It is the equivalent of writing: if (b->key)

To see that the code is correct, you can write down the truth table of the *bitwise* AND operator: | b->ttype != TYPE_void | b->tkey || (b->ttype != TYPE_void) & b->tkey | |-----------------------+--------------++-----------------------------------| | false (== 0) | false (== 0) || 0 (== false) | | true (== 1) | false (== 0) || 0 (== false) | | false (== 0) | true (== 1) || 0 (== false) | | true (== 1) | true (== 1) || 1 (== true) | With a little thought you can see that this is the same as the *logical* AND operator. It works because both operands are of type bool, so their values are 0 for false and 1 for true in C99 if you cast them to integral types. (see for example the answers to this Stack Overflow question: https://stackoverflow.com/questions/4767923/c99-boolean-data-type) As Sjoerd wrote in his email the only difference might be a performance penalty in case the first operand is true, if the second operand is expensive to evaluate. This is not the case here because b->tkey is a bool value so its evaluation is cheap. In any case, if you find a particular set of inputs where this (or any other) part of the code produces wrong results we would be interested to see a bug report. Hope this helps, Panos.

Was that the intention of the original author of the code?

regards, Ranier Vilela

_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list

On 03/08/2020 17.40, Ranier Vilela wrote:

Em seg., 3 de ago. de 2020 às 12:18, Panagiotis Koutsourakis mailto:panagiotis.koutsourakis@monetdbsolutions.com> escreveu:

Hi Ranier,

On 8/3/20 4:59 PM, Ranier Vilela wrote: > Em seg., 3 de ago. de 2020 às 10:53, Gregory Burd mailto:greg@burd.me> escreveu: > >> Sjoerd, >> >> Nice explanation, so if they are both correct and one avoids unnecessary >> work (even just a tiny bit) why not adjust the code to add your explanation >> as a comment and use the more efficient version? >> > I'm not sure that is correct. > It is the equivalent of writing: > if (b->key)

To see that the code is correct, you can write down the truth table of the *bitwise* AND operator:

| b->ttype != TYPE_void | b->tkey      || (b->ttype != TYPE_void) & b->tkey | |-----------------------+--------------++-----------------------------------| | false (== 0)          | false (== 0) || 0 (== false)                      | | true  (== 1)          | false (== 0) || 0 (== false)                      | | false (== 0)          | true  (== 1) || 0 (== false)                      | | true  (== 1)          | true  (== 1) || 1 (== true)                       |

With a little thought you can see that this is the same as the *logical* AND operator. It works because both operands are of type bool, so their values are 0 for false and 1 for true in C99 if you cast them to integral types. (see for example the answers to this Stack Overflow question: https://stackoverflow.com/questions/4767923/c99-boolean-data-type)

As Sjoerd wrote in his email the only difference might be a performance penalty in case the first operand is true, if the second operand is expensive to evaluate. This is not the case here because b->tkey is a bool value so its evaluation is cheap.

In any case, if you find a particular set of inputs where this (or any other) part of the code produces wrong results we would be interested to see a bug report.

int main () {     bool r = true;     bool key = false;     const char * ptr = "not null";     void * pvoid = NULL;

    r = (ptr != pvoid);     if (r)        printf("true\n");     else        printf("false\n");

    r = ((ptr != pvoid) & key);     if (r)        printf("true");     else        printf("false");     return 0; }

output: true true

output: true false

Always output the key value, be true or false: try: key = true or key = false

Again (&) bitwise is not shortcut and only with C++ that bool is guaranted whatever 0 or 1.

The first part of the expression was a comparison of a pointer with NULL. An explicit compare operation (here !=) by definition of the C language always results in 0 or 1. And a bool value also, by definition of the C language, evaluates to 0 or 1.

regards, Ranier Vilela

_______________________________________________ developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list

-- Sjoerd Mullender