Re: Interval Comparisons

On 09/06/2024 12:26, David Brown wrote:

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.

Really,  checking that A and B both have the same value X is that unusual?

Of course, I have no idea what "x.tag" or "ti64" represent,

Here .tag contains type info, and it is checking that objects x and y both have type i64.

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

I think both alternates are fine if you did not have the feature being discussed. Although you might prefer the first if b was a more elaborate expression than is shown here.
It does put the onus on the compiler to ensure that repeated terms (there are four rather than three) is coded efficiently.
Not that the chained version can also be expressed as 'if a = 0 = b' for a 3-way comparison.

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.

If you have several such names, you can still write the wrong one!
Where you have a relationship that naturally involves 3 terms, and you express it with 4, then one of them needs to be repeated. But the language cannot enforce that extra term being one of the first three.
The programmer also now has to deal with a repeated time that might have side-effects.

 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.

Using function-like syntax is OK when you have the same operator between multiple terms. 'rising' could have '<' or '<='.
All-equal would have the same operator too, but it looks clunkier, and a bit over-the-top:
    a = b                2 terms
    all_equal(a, b, c)   3 terms using your feature
    a = b = c            3 terms using chained ops
    rising(a, b, c)      Using your other feature
    a <= b <= c          Using the same chained-op feature
Your solution requires a heavyweight language feature. It also looks like it will generate a lot of intermediate code that will need a heavyweight optimiser to tear down again.