Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Interval Comparisons
Date: Fri, 7 Jun 2024 13:20:33 +0100
Organization: A noiseless patient Spider
Lines: 117
Message-ID: <v3utuh$22afr$1@dont-email.me>
References: <v3merq$b1uj$1@dont-email.me>
 <pan$63fde$3c88716e$c61af1ee$d0a27c97@invalid.invalid>
 <v3o706$kfrm$2@dont-email.me> <v3o7jr$ki9u$1@dont-email.me>
 <v3of4h$pbb1$1@dont-email.me> <v3t0aa$1k8ck$2@dont-email.me>
 <v3tene$1n5ge$1@dont-email.me> <v3tlkj$1of9j$1@dont-email.me>
 <v3tqji$1t2fv$1@dont-email.me> <87bk4dz9ve.fsf@nosuchdomain.example.com>
 <v3ujg5$20s0s$1@dont-email.me> <v3unc7$20up1$1@dont-email.me>
 <v3uq8u$21i37$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 07 Jun 2024 14:20:33 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="29f6a6cdd40af68cde491d55d42bbb4c";
	logging-data="2173435"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18QOLHB1fq8F5qCG3a0kyjX"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:r6s0mqBo+VeY2rb94OkfztQpHXg=
In-Reply-To: <v3uq8u$21i37$2@dont-email.me>
Content-Language: en-GB
Bytes: 5247

On 07/06/2024 12:17, David Brown wrote:
> On 07/06/2024 12:28, bart wrote:
>> On 07/06/2024 10:22, David Brown wrote:

>>  >  I
>>  > have never found them helpful in Python coding, and I can't imagine 
>> them
>>  > being of any interest in my C code.
>>
>> The most common uses for me are comparing that N terms are equal (here 
>> = means equality):
>>
>>    if x.tag = y.tag = ti64
>>    if a = b = 0
>>
> 
> These do not correspond to what you want to say.
> 
> If someone has balloons, and you want to check that they have 2 red 
> balloons and two yellow balloons, you do start off by checking if the 
> number of red balloons is the same as the number of yellow balloons, and 
> then that the number of yellow balloons is 2.

("you don't"?)

That's not quite the intent of my examples, which is:

(1) That x.tag/y.tag or a/b are equal to each other

(2) That they also have a particular value


> Code syntax should, where practical, reflect its purpose and intent. You 
> should therefore write (adjusting to C, Python, or your own syntax as 
> desired) :
> 
>      if red_balloons == 2 and yellow_balloons == 2 ...

Here that connection is lost. You might infer it, but you don't know 
whether, at some point, the program could be changed to require 3 red 
balloons, while still needing 2 yellow ones.

Or someone could just write 3 by mistake. By repeating such terms, there 
is more opportunity for mistakes, and the connection between terms is 
looser.

Here is another real example, first written in static code (not in C; 
I've shortened 'sample' to avoid line-wrap):

     if hdr.hsamp[2] = hdr.vsamp[2] = hdr.hsamp[3] = hdr.vsamp[3] and
             (hdr.hsamp[1] <= 2 and hdr.vsamp[1] <= 2) then

         pimage := loadcolour(fs, hdr.hsamp[1], hdr.vsamp[1])

and here in dynamic code:

     (vsample1, vsample2, vsample3) := hdr.vsample
     (hsample1, hsample2, hsample3) := hdr.hsample
     ...
     if hsample2 = vsample2 = hsample3 = vsample3 and
             (hsample1 <= 2 and vsample1 <=2 ) then
         ....

Both check that 4 terms are identical, but there is no specific value 
they have to be.

(It would have been nice to avoid that repetition of '2' in that second 
test, but that's more difficult to achieve. There, hsample1/vsample1 
don't need to have the same value.

It's expressible as something like 'reduce(and, map(<=, (a, b), 2)' but 
that's using a sledgehammer just to avoid that duplicate '2'. It's not 
suited to lower-level code either.)










> If you don't want to write the "magic number" 2 twice, you give it a name :
> 
>      expected_balloons = 2
>      if red_balloons == expected_balloons
>          and yellow_balloons == expected_balloons...
> 
> 
>> I also used them for range-checking:
>>
>>    if a <= b <= c
>>
>> until I introduced 'if b in a..c' for that purpose. (However I would 
>> still need 'a <= b <= c' for floating point.)
> 
> Using "in" and a range or interval syntax would usually be clearer, and 
> closer to the intended meaning, IMHO.
> 
> Both of these chained shortcuts are used in mathematics, so they are not 
> unfamiliar.  But in writing mathematics, compared to programming, you 
> have a lot more freedom to expect the reader to interpret things 
> sensibly, and vastly more freedom in layout while also having an 
> incentive to keep things compact.  Good or common mathematical syntax 
> does not necessarily translate directly to good programming syntax.
> 
>>
>> What I might then suggest for C, as a first step, is to allow only 
>> chained '==' comparisons. That avoids those ambiguous cases, and also 
>> the problem with mixed precedence, while still providing a handy new 
>> feature.
>>
> 
> 
>