From: ben.usenet@bsb.me.uk   
      
   "Dmitry A. Kazakov"  writes:   
      
   > On 2022-11-29 16:03, Richard Harnden wrote:   
   >   
   >> Okay, so how about this ... ?   
   >> int in_subrange(int_fast64_t range_min, int_fast64_t range_max,   
   >> int_fast64_t start, int_fast64_t end, int_fast64_t check)   
   >> {   
   >>      while ( check < range_min )   
   >>          check += range_max - range_min;   
   >   
   > Ring modulo would be range_max - range_min + 1   
   >   
   >> It's okay for check to have 'clocked', range_min, range_max, start   
   >> and end have sensible values.   
   >   
   > If the language supports modular and ranged types there is no need to   
   > check/normalize arguments.   
      
   Part of the specification was that the inputs were intended to be valid,   
   though maybe that was not very clear.  In the case where this cropped   
   up, everything was in minutes coming from internal clocks and calendars   
   where the result were already in the 0-59 range.   
      
   In my view, if you need to check the arguments, that's a separate   
   function because what to do with bad data is so often   
   application-specific.  Just normalising and carrying on is only one   
   strategy, and one that can delay detecting bugs.  In your solution, you   
   normalised the degrees, minutes and seconds into a longitude beforehand,   
   which is all that was needed in that example.   
      
   --   
   Ben.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)