Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Interval Comparisons
Date: Fri, 7 Jun 2024 13:17:50 +0200
Organization: A noiseless patient Spider
Lines: 77
Message-ID: <v3uq8u$21i37$2@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 07 Jun 2024 13:17:50 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ec5c1f9082215424827ae25d429fe7a7";
	logging-data="2148455"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+VIZP7puntRuN70N3nADDfKZE9yOZDfvE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:dxvgzaIOl5a8OBSJqTL7fKBaRio=
In-Reply-To: <v3unc7$20up1$1@dont-email.me>
Content-Language: en-GB
Bytes: 3884

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


> So the restrictions I would suggest are:
> 
> * Not mixing <, <= with >, >= in the same chain (any angle brackets
>    should point the same way)
> 
> * Not allowing != in the chain.
> 

I think these are good ideas.

> 
> Such a chain also requires that all 6 (or 5) operators have the same 
> precedence, as you can't have 'a = b <= c' mean 'a = (b <= c)'.
> 
> 
>  >  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.

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 ...

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.
>