Re: Interval Comparisons

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