tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
i was unable ro remember that

On 27.03.2024 12:35, fir wrote:
> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))

1. As long as K&R precedences still hold you don't need the inner
parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
2. In this case where you compare predicate expressions that
evaluate to '0' and '1' on both sides of '&' and '&&' respectively
these expressions are (while not the same) equivalent _here_. If
you don't want to operate on bits but want to express a boolean
conjunction you should use '&&', though.

> i was unable ro remember that

You could look that up if you cannot remember that. Wikipedia[*]
has a page with a lot information, and a concise list you can,
for example, find here:
https://www.cs.uic.edu/~i109/Notes/COperatorPrecedenceTable.pdf

Janis

[*] https://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B

Janis Papanagnou wrote:
> On 27.03.2024 12:35, fir wrote:
>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>
> 1. As long as K&R precedences still hold you don't need the inner
> parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
> 2. In this case where you compare predicate expressions that
> evaluate to '0' and '1' on both sides of '&' and '&&' respectively
> these expressions are (while not the same) equivalent _here_. If
> you don't want to operate on bits but want to express a boolean
> conjunction you should use '&&', though.
>

ok tnx much this is quite solid answer

imagine i began to learn c in a week when WTC attack was (maybe like
about wednesday after that if it was friday (im not sure but somethin
about that) and wtill dont memrized those pices - but the answer of the
above is easy to remember "<" stronger than "&"

hovever i wopuld disagre to use "&&" instead "&" then
&& look much worse and probably & has no real disadvantages (i mean no
bigger that the intention that && should be use for boolean - which
probably comes from later c not oryginal young c

so i probably plan to stick to &

>> i was unable ro remember that
>
> You could look that up if you cannot remember that. Wikipedia[*]
> has a page with a lot information, and a concise list you can,
> for example, find here:
> https://www.cs.uic.edu/~i109/Notes/COperatorPrecedenceTable.pdf
>
> Janis
>
> [*] https://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B
>

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 27.03.2024 12:35, fir wrote:
>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>
>1. As long as K&R precedences still hold you don't need the inner
>parentheses; '<' and '<=' has higher precedence than '&' and '&&'.

While true, the parenthesis can be helpful to the reader
and have no adverse effects.

On 28.03.2024 13:18, fir wrote:
> Janis Papanagnou wrote:
>> On 27.03.2024 12:35, fir wrote:
>>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>>
>> [...] If
>> you don't want to operate on bits but want to express a boolean
>> conjunction you should use '&&', though.
>
> [...]
>
> hovever i wopuld disagre to use "&&" instead "&" then
> && look much worse

(Well, I think that '+' looks much worse than '*', but in
math expressions I use the _appropriate_ operator anyway.)

Mind that '&' is *not* a syntactical variant of '&&'...

> and probably & has no real disadvantages

it is different to '&&', it has another semantic! As said,
it's just by context-coincidence that it's equivalent _here_.

> (i mean no
> bigger that the intention that && should be use for boolean - which
> probably comes from later c not oryginal young c

Original K&R C had '&' for bit-operations and '&&' for boolean
operations.

While, say, 'x<y & u<v' works effectively as 'x<y && u<v' (as
said, because of the evaluations to 0 and 1, general boolean
predicates, like 'p() & q()' is not the same as 'p() && q()',
even if you can use 'p()' and 'q()' in 'if'-conditions as per
the C semantics of booleans (or integers used as booleans).

You often see code like,say, 'x=length(s); y=length(t);' and
compare non-emptiness of the strings with 'if (x)' or with
'if (y)'. If you combine that condition by 'if (x & y)' you
will get wrong results, but 'if (x && y)' would be correct.

'&' is for bit-operations in scalars, '&&' is for booleans
(for logical operations, bool x bool -> bool).

>
> so i probably plan to stick to &

But why stick to a bit-value operator where you want a
boolean logic operator? - You just confuse readers of your
code and unnecessarily introduce error-prone code.

(But you can of course do as you like.)

Janis

Janis Papanagnou wrote:
> On 28.03.2024 13:18, fir wrote:
>> Janis Papanagnou wrote:
>>> On 27.03.2024 12:35, fir wrote:
>>>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>>>
>>> [...] If
>>> you don't want to operate on bits but want to express a boolean
>>> conjunction you should use '&&', though.
>>
>> [...]
>>
>> hovever i wopuld disagre to use "&&" instead "&" then
>> && look much worse
>
> (Well, I think that '+' looks much worse than '*', but in
> math expressions I use the _appropriate_ operator anyway.)
>
> Mind that '&' is *not* a syntactical variant of '&&'...
>
>> and probably & has no real disadvantages
>
> it is different to '&&', it has another semantic! As said,
> it's just by context-coincidence that it's equivalent _here_.
>
>> (i mean no
>> bigger that the intention that && should be use for boolean - which
>> probably comes from later c not oryginal young c
>
> Original K&R C had '&' for bit-operations and '&&' for boolean
> operations.
>
> While, say, 'x<y & u<v' works effectively as 'x<y && u<v' (as
> said, because of the evaluations to 0 and 1, general boolean
> predicates, like 'p() & q()' is not the same as 'p() && q()',
> even if you can use 'p()' and 'q()' in 'if'-conditions as per
> the C semantics of booleans (or integers used as booleans).
>
> You often see code like,say, 'x=length(s); y=length(t);' and
> compare non-emptiness of the strings with 'if (x)' or with
> 'if (y)'. If you combine that condition by 'if (x & y)' you
> will get wrong results, but 'if (x && y)' would be correct.
>

how, if string ate empty then the pionters are nulls to
null&null should work ok imo

> '&' is for bit-operations in scalars, '&&' is for booleans
> (for logical operations, bool x bool -> bool).
>
>>
>> so i probably plan to stick to &
>
> But why stick to a bit-value operator where you want a
> boolean logic operator? - You just confuse readers of your
> code and unnecessarily introduce error-prone code.
>
> (But you can of course do as you like.)
>
> Janis
>
becouse this && is ugly i think the addition of && is kinda error
in language

On 28/03/2024 16:28, fir wrote:
> Janis Papanagnou wrote:
>> On 28.03.2024 13:18, fir wrote:
>>> Janis Papanagnou wrote:
>>>> On 27.03.2024 12:35, fir wrote:
>>>>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>>>>
>>>> [...] If
>>>> you don't want to operate on bits but want to express a boolean
>>>> conjunction you should use '&&', though.
>>>
>>> [...]
>>>
>>> hovever i wopuld disagre to use "&&" instead "&" then
>>> && look much worse
>>
>> (Well, I think that '+' looks much worse than '*', but in
>> math expressions I use the _appropriate_ operator anyway.)
>>
>> Mind that '&' is *not* a syntactical variant of '&&'...
>>
>>> and probably & has no real disadvantages
>>
>> it is different to '&&', it has another semantic! As said,
>> it's just by context-coincidence that it's equivalent _here_.
>>
>>> (i mean no
>>> bigger that the intention that && should be use for boolean - which
>>> probably comes from later c not oryginal young c
>>
>> Original K&R C had '&' for bit-operations and '&&' for boolean
>> operations.
>>
>> While, say, 'x<y & u<v' works effectively as 'x<y && u<v' (as
>> said, because of the evaluations to 0 and 1, general boolean
>> predicates, like 'p() & q()' is not the same as 'p() && q()',
>> even if you can use 'p()' and 'q()' in 'if'-conditions as per
>> the C semantics of booleans (or integers used as booleans).
>>
>> You often see code like,say, 'x=length(s); y=length(t);' and
>> compare non-emptiness of the strings with 'if (x)' or with
>> 'if (y)'. If you combine that condition by 'if (x & y)' you
>> will get wrong results, but 'if (x && y)' would be correct.
>>
>
> how, if string ate empty then the pionters are nulls to
> null&null should work ok imo

Aren't x and y integers? An empty string is presumably "" (not NULL) and
length("") should be 0.

>> But why stick to a bit-value operator where you want a
>> boolean logic operator? - You just confuse readers of your
>> code and unnecessarily introduce error-prone code.
>>
>> (But you can of course do as you like.)

> becouse this && is ugly i think the addition of && is kinda error
> in language

Of all the ugly things in C, you have to pick on &&? In any case, that's
the correct operator to use here, since && is quite different from &:

if (length(s) & length(t))

if (length(s) && length(t))

Suppose s is "AB" and t is "ABCD". Then the version using & will do 2 &
4 which is zero: so FALSE.

The version using && will be 2 && 4 which is 1, so TRUE, a completely
different result.

Also, if s was "", then the version using && short-circuits, so it won't
bother evaluating length(t); it is more efficient.

Also, as you've discovered, & has a different and less suitable
precedence compared to &&.

If you really hate '&&' then try including <iso646.h>. Now you can do this:

if (length(s) and length(t))

But let me guess; that's too long-winded? 'A and B' instead of 'A&&B'
because 'and' needs that white space.

bart wrote:
> On 28/03/2024 16:28, fir wrote:
>> Janis Papanagnou wrote:
>>> On 28.03.2024 13:18, fir wrote:
>>>> Janis Papanagnou wrote:
>>>>> On 27.03.2024 12:35, fir wrote:
>>>>>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>>>>>
>>>>> [...] If
>>>>> you don't want to operate on bits but want to express a boolean
>>>>> conjunction you should use '&&', though.
>>>>
>>>> [...]
>>>>
>>>> hovever i wopuld disagre to use "&&" instead "&" then
>>>> && look much worse
>>>
>>> (Well, I think that '+' looks much worse than '*', but in
>>> math expressions I use the _appropriate_ operator anyway.)
>>>
>>> Mind that '&' is *not* a syntactical variant of '&&'...
>>>
>>>> and probably & has no real disadvantages
>>>
>>> it is different to '&&', it has another semantic! As said,
>>> it's just by context-coincidence that it's equivalent _here_.
>>>
>>>> (i mean no
>>>> bigger that the intention that && should be use for boolean - which
>>>> probably comes from later c not oryginal young c
>>>
>>> Original K&R C had '&' for bit-operations and '&&' for boolean
>>> operations.
>>>
>>> While, say, 'x<y & u<v' works effectively as 'x<y && u<v' (as
>>> said, because of the evaluations to 0 and 1, general boolean
>>> predicates, like 'p() & q()' is not the same as 'p() && q()',
>>> even if you can use 'p()' and 'q()' in 'if'-conditions as per
>>> the C semantics of booleans (or integers used as booleans).
>>>
>>> You often see code like,say, 'x=length(s); y=length(t);' and
>>> compare non-emptiness of the strings with 'if (x)' or with
>>> 'if (y)'. If you combine that condition by 'if (x & y)' you
>>> will get wrong results, but 'if (x && y)' would be correct.
>>>
>>
>> how, if string ate empty then the pionters are nulls to
>> null&null should work ok imo
>
> Aren't x and y integers? An empty string is presumably "" (not NULL) and
> length("") should be 0.
>
>>> But why stick to a bit-value operator where you want a
>>> boolean logic operator? - You just confuse readers of your
>>> code and unnecessarily introduce error-prone code.
>>>
>>> (But you can of course do as you like.)
>
>> becouse this && is ugly i think the addition of && is kinda error
>> in language
>
> Of all the ugly things in C, you have to pick on &&? In any case, that's
> the correct operator to use here, since && is quite different from &:
>
> if (length(s) & length(t))
>
> if (length(s) && length(t))
>
> Suppose s is "AB" and t is "ABCD". Then the version using & will do 2 &
> 4 which is zero: so FALSE.
>
> The version using && will be 2 && 4 which is 1, so TRUE, a completely
> different result.
>
> Also, if s was "", then the version using && short-circuits, so it won't
> bother evaluating length(t); it is more efficient.
>
> Also, as you've discovered, & has a different and less suitable
> precedence compared to &&.
>
>
> If you really hate '&&' then try including <iso646.h>. Now you can do this:
>
> if (length(s) and length(t))
>
> But let me guess; that's too long-winded? 'A and B' instead of 'A&&B'
> because 'and' needs that white space.

should be A&B and everything looks liek it should

thsoe with length are weird programming i dont use it,
using & is not totally proper taking c history but && for me is also not
fully proper taking c 'style' and & i find just better

On 28/03/2024 15:14, Scott Lurndal wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 27.03.2024 12:35, fir wrote:
>>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>>
>> 1. As long as K&R precedences still hold you don't need the inner
>> parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
>
> While true, the parenthesis can be helpful to the reader
> and have no adverse effects.
>

A couple of space characters would also not go amiss in aiding the reader.

On 2024-03-28, David Brown <david.brown@hesbynett.no> wrote:
> On 28/03/2024 15:14, Scott Lurndal wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> On 27.03.2024 12:35, fir wrote:
>>>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>>>
>>> 1. As long as K&R precedences still hold you don't need the inner
>>> parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
>>
>> While true, the parenthesis can be helpful to the reader
>> and have no adverse effects.
>
> A couple of space characters would also not go amiss in aiding the reader.

But that "fir" *is* a space character.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 28/03/2024 17:12, fir wrote:
> bart wrote:

>> Of all the ugly things in C, you have to pick on &&? In any case, that's
>> the correct operator to use here, since && is quite different from &:
>>
>>      if (length(s) & length(t))
>>
>>      if (length(s) && length(t))
>>
>> Suppose s is "AB" and t is "ABCD". Then the version using & will do 2 &
>> 4 which is zero: so FALSE.
>>
>> The version using && will be 2 && 4 which is 1, so TRUE, a completely
>> different result.
>>
>> Also, if s was "", then the version using && short-circuits, so it won't
>> bother evaluating length(t); it is more efficient.
>>
>> Also, as you've discovered, & has a different and less suitable
>> precedence compared to &&.
>>
>>
>> If you really hate '&&' then try including <iso646.h>. Now you can do
>> this:
>>
>>      if (length(s) and length(t))
>>
>> But let me guess; that's too long-winded? 'A and B' instead of 'A&&B'
>> because 'and' needs that white space.
>
> should be A&B and everything looks liek it should

You haven't read my post properly have you?

& and && do quite different things; I listed 3 major ways in which they
differ.

Here's another:

float x=k, y=k;
if (x && y) // this will work as expected
if (x & y) // this won't compile

> thsoe with length are weird programming i dont use it,
> using & is not totally proper taking c history but && for me is also not
> fully proper taking c 'style' and & i find just better

OK. You can make & work a bit like && if you turn:

A && B

where A and B are arbitrary expressions, into:

!!(A) & !!(B)

But you still won't get short-circuit behaviour.

bart wrote:
> On 28/03/2024 17:12, fir wrote:
>> bart wrote:
>
>>> Of all the ugly things in C, you have to pick on &&? In any case, that's
>>> the correct operator to use here, since && is quite different from &:
>>>
>>> if (length(s) & length(t))
>>>
>>> if (length(s) && length(t))
>>>
>>> Suppose s is "AB" and t is "ABCD". Then the version using & will do 2 &
>>> 4 which is zero: so FALSE.
>>>
>>> The version using && will be 2 && 4 which is 1, so TRUE, a completely
>>> different result.
>>>
>>> Also, if s was "", then the version using && short-circuits, so it won't
>>> bother evaluating length(t); it is more efficient.
>>>
>>> Also, as you've discovered, & has a different and less suitable
>>> precedence compared to &&.
>>>
>>>
>>> If you really hate '&&' then try including <iso646.h>. Now you can do
>>> this:
>>>
>>> if (length(s) and length(t))
>>>
>>> But let me guess; that's too long-winded? 'A and B' instead of 'A&&B'
>>> because 'and' needs that white space.
>>
>> should be A&B and everything looks liek it should
>
> You haven't read my post properly have you?
>
> & and && do quite different things; I listed 3 major ways in which they
> differ.
>
> Here's another:
>
> float x=k, y=k;
> if (x && y) // this will work as expected
> if (x & y) // this won't compile
>

i dont use it this way - not this one with length ..literally never used
it this way -

probably all teh usecases i use it the & will fit (not sure though but
this can be seen)

>
>
>> thsoe with length are weird programming i dont use it,
>> using & is not totally proper taking c history but && for me is also
>> not fully proper taking c 'style' and & i find just better
>
> OK. You can make & work a bit like && if you turn:
>
> A && B
>
> where A and B are arbitrary expressions, into:
>
> !!(A) & !!(B)
>
> But you still won't get short-circuit behaviour.
>

scott@slp53.sl.home (Scott Lurndal) writes:

> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> On 27.03.2024 12:35, fir wrote:
>>
>>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>>
>> 1. As long as K&R precedences still hold you don't need the inner
>> parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
>
> While true, the parenthesis can be helpful to the reader
> and have no adverse effects.

Certainly extra parentheses can be helpful to some readers.

Considered as a question of fact, the proposition that extra
parentheses have no adverse effects is false. It may be the
case that the adverse effects are thought to be unimportant
relative to some proposed benefit, but that is a question of
opinion rather than a question of fact.

Tim Rentsch wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>>> On 27.03.2024 12:35, fir wrote:
>>>
>>>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>>>
>>> 1. As long as K&R precedences still hold you don't need the inner
>>> parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
>>
>> While true, the parenthesis can be helpful to the reader
>> and have no adverse effects.
>
> Certainly extra parentheses can be helpful to some readers.
>
> Considered as a question of fact, the proposition that extra
> parentheses have no adverse effects is false. It may be the
> case that the adverse effects are thought to be unimportant
> relative to some proposed benefit, but that is a question of
> opinion rather than a question of fact.
>

what a lamas you are ...

its quite oposite it is using parenthesis and && instead of & and ||
insetad | makes c source code lost its character - its generaly weird
world that i noticed it recenty not 20 years ago

Scott Lurndal wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 27.03.2024 12:35, fir wrote:
>>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>>
>> 1. As long as K&R precedences still hold you don't need the inner
>> parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
>
> While true, the parenthesis can be helpful to the reader
> and have no adverse effects.
>

i think i will use the rule if the operator precedences are right

(and here ARITHM < REL < LOG rule is ruight) i will not use parenthesis
but when its wrong i will use them (probably even if they are not needed)

if(!(i%16)) for example i must use it becouse if(!i%16) sadly and
unproperly dont work

Groovy hepcat fir was jivin' in comp.lang.c on Wed, 27 Mar 2024 10:35
pm. It's a cool scene! Dig it.

> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
> i was unable ro remember that

You're forgetting that && is a so-called "short circuit" operator. If
the left operand is false, then the right operand is not evaluated.
This makes little difference in this particular case; but what if you
had something like this instead?

while(some_function() < p && some_other_function() <= r)

Here some_other_function() will not be called if the some_function()
call returns a value >= p.

--

----- Dig the NEW and IMPROVED news sig!! -----

-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

Peter 'Shaggy' Haywood wrote:
> Groovy hepcat fir was jivin' in comp.lang.c on Wed, 27 Mar 2024 10:35
> pm. It's a cool scene! Dig it.
>
>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>> i was unable ro remember that
>
> You're forgetting that && is a so-called "short circuit" operator. If
> the left operand is false, then the right operand is not evaluated.
> This makes little difference in this particular case; but what if you
> had something like this instead?
>
> while(some_function() < p && some_other_function() <= r)
>
> Here some_other_function() will not be called if the some_function()
> call returns a value >= p.
>

okay, good point, need to remember that - but anyway there is a wide
aspect of usecases (roughly 100 procent of mine if im not wrong where
i can replace those poor && and || by really good loking & and |

fir <fir@grunge.pl> writes:

> Tim Rentsch wrote:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>
>>>> On 27.03.2024 12:35, fir wrote:
>>>>
>>>>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>>>>
>>>> 1. As long as K&R precedences still hold you don't need the inner
>>>> parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
>>>
>>> While true, the parenthesis can be helpful to the reader
>>> and have no adverse effects.
>>
>> Certainly extra parentheses can be helpful to some readers.
>>
>> Considered as a question of fact, the proposition that extra
>> parentheses have no adverse effects is false. It may be the
>> case that the adverse effects are thought to be unimportant
>> relative to some proposed benefit, but that is a question of
>> opinion rather than a question of fact.
>
> what a lamas you are ...
>
> its quite oposite it is using parenthesis and && instead of & and ||
> insetad | makes c source code lost its character - its generaly weird
> world that i noticed it recenty not 20 years ago

Can you explain how your comment has some relationship
to what it was that I said? What is it that you think
I did say?

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 27.03.2024 12:35, fir wrote:
>> tell me, is while(T[l]<p & l<=r) the same as while((T[l]<p)&&(l<=r))
>
> 1. As long as K&R precedences still hold you don't need the inner
> parentheses; '<' and '<=' has higher precedence than '&' and '&&'.
> 2. In this case where you compare predicate expressions that
> evaluate to '0' and '1' on both sides of '&' and '&&' respectively
> these expressions are (while not the same) equivalent _here_.

The latter has shortcut semantics, and will only evaluate
r, and l a second time, if the first expression is true.
If r or l are memory mapped I/O, or similar, you might be
changing externally visible behaviour.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/