home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.programming      Programming issues that transcend langua      57,431 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 56,827 of 57,431   
   Tim Rentsch to Mike Terry   
   Re: Another little puzzle   
   25 Dec 22 00:37:47   
   
   From: tr.17687@z991.linuxsc.com   
      
   Mike Terry  writes:   
      
   > On 24/12/2022 14:21, Tim Rentsch wrote:   
   >   
   >> Ben Bacarisse  writes:   
   >>   
   >>> Tim Rentsch  writes:   
   >>>   
   >>>> ram@zedat.fu-berlin.de (Stefan Ram) writes:   
   >>>>   
   >>>>> ram@zedat.fu-berlin.de (Stefan Ram) writes:   
   >>>>>   
   >>>>>> Given n times of the 24-hour day, print their average.   
   >>>>>> For example, the average of "eight o'clock" and   
   >>>>>> "ten o'clock" (n=2) would be "nine o'clock".   
   >>>>>> (You can choose any representation, for example "HH:MM"   
   >>>>>> or "seconds since midnight".)   
      
   [...]   
      
   >>> The input is a collection, t(n), of n > 1 numbers in [0, 24).  The   
   >>> average should be a number, A, in [0, 24) that minimises   
   >>>   
   >>>    Sum_{i=1,n} distance(A, t(i))   
   >>>   
   >>> (or Sum_{i=1,n} difference(A, t(i))^2 if you prefer to think in terms   
   >>> of variance).  So far, this is just what an average is.  The key point   
   >>> is what is the distance (or difference) whose sum (or sum of squares)   
   >>> we want to minimise?  For times, I would say it is the length of the   
   >>> shorter arc round an imaginary 24-hour clock face.   
   >>   
   >> Minimizing the square of the distance (aka length of the shorter   
   >> arc) is one metric, and I think a reasonable one.  [...]   
   >   
   > Yes - perhaps Ben was thinking of making   
   >   
   >    Sum_{i=1,n} signed_distance(A, t(i))  =  0   
   >   
   > rather than minimising the (absolute) distance. [...]   
      
   I think Ben meant what he said, but I will let him speak for   
   himself.   
      
   >>> The problem has a natural interpretation in terms of angles.   
   >>> Whatever the circular quantity is, convert the values to unit   
   >>> vectors round a circle.  For times of day, just scale [0, 24) to   
   >>> [0, 2*pi).  The average is then just the direction of the average   
   >>> vector, converted back to a time of day.   
   >>   
   >> Averaging the "time unit vectors" is another plausible metric.   
   >   
   > Yes I think this one would work best in most situations, [...]   
      
   It gives results in many cases, including many easy cases, that I   
   think would surprise most people.   
      
   > Another way of thinking of this approach is "balancing" the 24-hour   
   > modular circle, where we've put unit weights at each of the times   
   > x_i.  E.g. we look for a balancing line through the centre of the   
   > circle.  [Note times on the circle go from 1-24, not 1-12 like a   
   > normal clock.]   
      
   To me this way of thinking about the problem seems not very   
   useful.   
      
   > Also, thinking like this, it's equivalent to (conventional)   
   > averaging of the sin of the angular differences from the average   
   > (balancing) point, since the sin will give the perpendicular   
   > distance of the weight from the balancing line. [...]   
      
   I think this statement is nonsensical.  We are taking the   
   conventional average of "something", but the "something" has   
   been chosen so that its conventional average is zero.  It's   
   like saying, Once you get to where you're going, you know that   
   where you're going is where you are.  There is no information   
   about how to solve the problem, and so it cannot be equivalent   
   to any method that provides an actual answer.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca