From: julio@diegidio.name   
      
   On Monday, 28 November 2022 at 16:22:38 UTC+1, Tim Rentsch wrote:   
   > Julio Di Egidio  writes:   
   > >>> On Monday, 21 November 2022 at 21:45:34 UTC+1, Ben Bacarisse wrote:   
   >   
   > > On Monday, 28 November 2022 at 04:23:28 UTC+1, Tim Rentsch wrote:   
   > >   
   > >> Julio Di Egidio  writes:   
   >   
   > I recommend switching away from google groups,   
      
   That is your prerogative, I suppose.   
      
   > >>>> Consider any ordered measure that "wraps round" -- bearings in   
   > >>>> degrees, minutes in the hour, indeed hours in either the 12 or 24   
   > >>>> hour clock. The problem is to determine if a given value is in   
   > >>>> the sub-range specified by a start and an en value.   
      
   > > Argh! But you should not have snipped that "beware   
   > > of bugs", that was the most important part!! ;)   
   >   
   > It's your job to beware of bugs, not mine.   
      
   I didn't know you were paying me for production level code:   
   in that case, I'd have asked for the technical requirements,   
   not just the functional ones...   
      
   IOW, I have have given a mathematical spec written in some   
   simply-typed functional language, can be functions on the real   
   numbers.  Which is often step one in functional/algorithmic   
   design.  Beside that point, one needs technical requirements,   
   i.e. info on the concrete numeric types available as a minimum.   
      
   > > This one should do the trick:   
   > >   
   > > ```ts   
   > > /** Returns whether x in [lo, hi[ (mod m). */   
   > > function inOpenModRange(   
   > > x: number, lo: number, hi: number, m: number   
   > > ): boolean {   
   > > let x_ = MOD(x - lo, m);   
   > > let hi_ = MOD(hi - lo, m);   
   > > return x_ < hi_;   
   > > }   
   > > ```   
   > This scheme looks like it will work, as long as the values given   
   > don't get too near the edges of representation. JavaScript   
   > represents numeric values using floating point, and that choice   
   > leads to some unexpected results when working with large numbers.   
   >   
   > However, this approach is more complicated than it needs to be.   
   > Have you tried looking at the other answers?   
      
   That is complicated??  Maybe I haven't looked well enough   
   but, honestly, I have not seen anything that is even vaguely as   
   clear, and efficient, and to the point.  Have I missed it?   
      
   Julio   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)