Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #16108

Re: Another little puzzle

Show all headers | View raw

On 21/12/2022 17:55, Dmitry A. Kazakov wrote:
> On 2022-12-21 18:05, Ben Bacarisse wrote:
> 
>> There is a
>> perfectly plausible interpretation of "average" that gives 0.5.
> 
> Not very plausible as it violates two properties of:
> 
>     min({Xi}) <= avr({Xi}) <= max({Xi})
> 
> and
> 
>     avr({C * Xi}) = C * avr({Xi})
> 
> The second one allows calculation of the average as:
> 
>     23.5 / 2 + 1.5 / 2 = ?
> 

Dmitri: while I'm replying to /your/ post, my points are not especially addressed to you - it's more 
of an accumulation of "frustration" at what I consider to be "unimaginative" misinterpretations and 
dogmatic claims of what was originally requested...  (I pretty much just chose a recent post and 
responded due to some internal threshold being reached! :) So don't be personally offended!)

A lot of people here have treated the problem as saying "find the numeric average of the number of 
seconds past midnight for a given set of times".  Well, clearly (to me) that is NOT what the OP 
intended, and I would say it's by no means the required meaning of the words he actually used.

It was pretty clear to me that the intention was (somehow) to look at the problem of averaging 
values in some kind of modular setting, e.g. times given with a 24 hour clock.  Such times wrap at 
midnight and common sense would say that we are to consider times a couple of minutes apart as 
"close" in this modular setting.  I.e. 2 minutes to midnight and 2 minutes past midnight should be 
considered separated by 4 minutes, not 23 hours 56 minutes.

The OP was probably deliberately rather vague on this point!  The easiest definition for "average" 
literally doesn't make sense in a modulo context:  we can ADD the modular values, but in general 
dividing in such a mathematical setting doesn't make much sense, so

     Average ([i=1,2,..n] x_i)  =[def]=  Sum ([i=1,2,..n] x_i) /n

would be inappropriate due to the /n operation.

HOWEVER, there's another characterisation for the average of a set, which looks more promising in a 
modular (or other more general) setting:  the average is the value of V which MINIMISES THE "ERROR" 
calculated by

     error = Sum ([i=1,2,..n] (V - x_i)^2)

that is, minimises the sum of squares of differences from V.  [Incidentally, if we minimise the sum 
of absolute differeces from V, that characterises the mode (aka "midpoint") of the sample, but I 
think the median is more what is wanted here...]

So I'll suggest a precise wording of what was (I think) wanted:  find the time V that minimises the 
error function above, based on "distances" in a modular setting.  We also need to make clear what 
"distance" means in that setting, but put like that I think there would be less disagreement that 
the sensible way to define the distance between two times, would be in the expected "wrapping" 
manor.  E.g. we could say the distance is the LEAST positive D such that V +- D = x_i, with the 
arithmetic + or - being modular arithmetic, i.e. mod 24hours.  Obviously this makes the distance 
between 23:58 and 00:02 4 minutes, like we want...

Had the OP suggested that the times in question were EVENTS, then obviously averaging the time for 
them is a concretely defined operation, but to interpret the OP like that, we would then need to 
turn "times" into "event occurences date+times" and there was no mention of dates anywhere - to me 
it's clear the times are just intended as modular 24hour times, not applying to specific events.

And for those that go further and suggest what was said was that the times were all events occuring 
on one and the same day, and that is what OP asked to be averaged - well!  (I don't think that is 
reasonable at all, to put it mildly.)

Now, as to how to CALCULATE the V above???

[I haven't got a definitive approach - obviously we could calculate the normal arithmetic "number of 
seconds past midnight" average, then look at adjusting it as we flip various x_i by 24hours, but 
there could be a lot of x_i to flip (problem grows exponentially).  Or maybe we sample V at a fixed 
number of places like on each hour, and (with luck) there may be an obvious minimum - at that point 
we could make a good guess for exactly which x_i should be "flipped" by 24hours, and then calculate 
using normal arithmetic averaging???  Well that's my first idea.]

Regards,
Mike.

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Another little puzzle Richard Heathfield <rjh@cpax.org.uk> - 2022-12-21 13:09 +0000
  Re: Another little puzzle Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-21 17:05 +0000
    Re: Another little puzzle Richard Heathfield <rjh@cpax.org.uk> - 2022-12-21 17:21 +0000
    Re: Another little puzzle "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-12-21 18:55 +0100
      Re: Another little puzzle Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-12-21 19:55 +0000
        Re: Another little puzzle "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-12-21 22:54 +0100
          Re: Another little puzzle Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-12-22 00:01 +0000
            Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-21 16:05 -0800
              Re: Another little puzzle David Brown <david.brown@hesbynett.no> - 2022-12-22 16:50 +0100
                Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-22 08:30 -0800
                Re: Another little puzzle David Brown <david.brown@hesbynett.no> - 2022-12-22 22:06 +0100
                Re: Another little puzzle Richard Heathfield <rjh@cpax.org.uk> - 2022-12-22 21:30 +0000
                Re: Another little puzzle David Brown <david.brown@hesbynett.no> - 2022-12-23 13:46 +0100
                Re: Another little puzzle Y A <angel0000000001000000000000@mail.ee> - 2023-01-09 21:26 -0800
                Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-22 14:15 -0800
                Re: Another little puzzle David Brown <david.brown@hesbynett.no> - 2022-12-23 13:47 +0100
                Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-23 08:33 -0800
                Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-25 15:52 -0800
                Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-26 06:32 -0800
                Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-26 06:34 -0800
              Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-23 08:35 -0800
            Re: Another little puzzle "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-12-22 09:10 +0100
          Re: Another little puzzle Ǝ <angel00000100000@mail.ee> - 2022-12-30 18:18 -0800
        Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-21 14:47 -0800
          Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-23 08:35 -0800
          Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-25 15:52 -0800
            Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-26 06:32 -0800
          Re: Another little puzzle Julio Di Egidio <julio@diegidio.name> - 2022-12-26 06:33 -0800
          Re: Another little puzzle Y A <angel0000000001000000000000@mail.ee> - 2023-01-09 21:26 -0800

csiph-web