From: tr.17687@z991.linuxsc.com   
      
   Richard Harnden  writes:   
      
   > On 30/11/2022 11:32, Tim Rentsch wrote:   
      
   [...]   
      
   >> Let's look again at the key test, simplified so as not to do the   
   >> range tests (some redundant parentheses retained):   
   >>   
   >>      if(   
   >>          (end < start && (check <= end || check >= start))   
   >>          ||  (check >= start && check <= end)   
   >>      ){   
   >>          return  1;   
   >>      }   
   >>   
   >> I think the logic of this test is right, but the form of it makes me   
   >> nervous.  The reason for that is the second line depends on the   
   >> condition 'start <= end' being true, but that condition is not   
   >> explicitly tested.  The condition is /implied/ by the tests that are   
   >> done against 'check', but that result is not immediately obvious.  I   
   >> think a better writing would be to use a ?: operator, as for example   
   >>   
   >>      if(   
   >>          end < start   
   >>              ?  start <= check  ||  check < end   
   >>              :  start <= check  &&  check < end   
   >>      ){   
   >>          return  1;   
   >>      }   
   >>   
   >> Now it is immediately obvious that the two cases are mutually   
   >> exclusive.   
   >>   
   >> Finally, consider the last two statements.  Since the penultimate   
   >> statement conditionally returns 1 (true) and the last statement   
   >> simply returns 0 (false), these two statements can be combined into   
   >> a single 'return' statement:   
   >>   
   >>      return   
   >>          end < start   
   >>              ?  start <= check  ||  check < end   
   >>              :  start <= check  &&  check < end   
   >>      ;   
   >   
   > And I think that is the solution you orignally gave (?)   
      
   Mathematically equivalent (my code used different operand orders).   
   Notice though that my derivation above simply started with your   
   code and went forward.  I wasn't re-engineering the problem, just   
   revising what you had written to put it in an easier-to-understand   
   form.  (I should add that I did modify the end boundary condition   
   test, but that is incidental.)  That the result was equivalent to   
   what I wrote shows that your original code has the same behavior   
   as mine, and only that;  I didn't mean to compare them or offer   
   any sort of correction (and in fact I wasn't thinking of what   
   I had written while I was replying to your posting).   
      
   >> (I hope you will excuse my tendency to try to simplify almost any   
   >> code that I see.  I appreciate what you've done here.)   
   >   
   > For me, vebose is simple and I'd only condense it down once I   
   > understand it / know its correct.   
      
   When I say "simplify" I don't mean make shorter but make it easier   
   for me to convince myself that the code is correct.  A lot of   
   times shorter code is easier to understand, but shortness is not   
   the metric for simplicity.  Code that makes it easier for me to   
   convince myself that the code is correct is simpler, no matter   
   how condensed or compact it is.  What motivated me here was that   
   the original code made it hard for me to convince myself that the   
   code was correct.   
      
   >> [...]   
      
   > Thanks for taking your time.   
      
   Thank you, it's always pleasing to hear appreciation for my   
   efforts.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)