Re: Interval Comparisons

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.