Re: Interval Comparisons

On 07/06/2024 14:20, bart wrote:

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"?)

Yes, sorry about that!

 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
 

If that is your intent, then fair enough.  But I think that is an unusual intent.  Of course, I have no idea what "x.tag" or "ti64" represent, and if I had, the code might have made more sense to me.
At least for the second example, if you did not have chaining equality, I think you would have preferred to write :
if (a = 0) and (b = 0) ...
rather than
if (a = b) and (b = 0) ...
If that is indeed the case, then IMHO the chaining version is less clear.

 

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.

Sure.  If this is a risk, use a separate constant (with appropriate name) for the numbers you want, and write that name rather than the number 2.

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

There comes a point when a function called "all_equal", or "rising", is the right choice.  How those functions might be implemented is a matter of language, and also whether you want them to work with a variable parameter list or over arrays, lists, slices, or whatever the language supports.  High-level functions like map and reduce could be part of this, along with folds.  For example, in C++ 17 (which supports a fold syntax), you might write :
template <typename H1>
constexpr bool rising(H1)
{
    return true;
}
template <typename H1, typename H2, typename ... T>
constexpr bool rising(H1 head1, H2 head2, T... tail)
{
    return head1 <= head2 && rising(head2, tail...);
}
Then
rising(a, b, c, d)
is interpreted as
a <= b && rising(b, c, d)
and so on.
I don't think it is fair to claim particular ways of writing these things are always clearer, or better, or uglier, or unclear - it will depend on the rest of the language, and how the code is used.  But in general I think it helps to write code that follows the logic of what the writer really means, rather than alternative constructions that give the same result.