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


Groups > comp.programming > #16081

Re: Another little puzzle

From "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups comp.programming
Subject Re: Another little puzzle
Date 2022-12-14 15:58 +0100
Organization Aioe.org NNTP Server
Message-ID <tncob5$1oat$1@gioia.aioe.org> (permalink)
References <puzzle-20221214131815@ram.dialup.fu-berlin.de> <tncho3$ilr$1@gioia.aioe.org> <tnci0u$2of9h$3@dont-email.me> <tncjem$19kh$1@gioia.aioe.org> <tnclg3$2of9o$2@dont-email.me>

Show all headers | View raw


On 2022-12-14 15:10, Richard Heathfield wrote:
> On 14/12/2022 1:35 pm, Dmitry A. Kazakov wrote:
>> On 2022-12-14 14:10, Richard Heathfield wrote:
>>> On 14/12/2022 1:06 pm, Dmitry A. Kazakov wrote:
>>>> On 2022-12-14 13:24, Stefan Ram wrote:
>>>>>    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 probably missed to require the interesting part: doing all that 
>>>> in the modular type (modulo 24) arithmetic:
>>>>
>>>>     20 + 5 = 1 (mod 24)
>>>
>>> ...which will give you the wrong answer. Chase that goose!
>>
>> Right, you must count the wrap-ups.

[...]

> So why do you need mod?

As I said, the challenge is only interesting in modulo arithmetic (24 or 
24*60 or 24*60*60). E.g. let

    type Hour is mod 24;

Average a series of Hour without conversion to another integer type.

(Otherwise it is trivial: convert to a wider type, average, convert back)

P.S. This problem may actually arise in programming a microcontroller 
when you have some large series and narrow 16-bit types. Close cases are 
computations with color channels and grayscale levels when conversions 
to wider types are too expensive etc.

The general case is some f(X1,X2,..,Xn) such that max{Xi} >= f() >= 
min{Xi}, but intermediates are not. As it is in the case with averaging Xi.

BTW, averaging floats is a nasty problem too. A naive implementation 
quickly loses precision.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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


Thread

Re: Another little puzzle "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-12-14 14:06 +0100
  Re: Another little puzzle Richard Heathfield <rjh@cpax.org.uk> - 2022-12-14 13:10 +0000
    Re: Another little puzzle "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-12-14 14:35 +0100
      Re: Another little puzzle Richard Heathfield <rjh@cpax.org.uk> - 2022-12-14 14:10 +0000
        Re: Another little puzzle "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-12-14 15:58 +0100
          Re: Another little puzzle Richard Heathfield <rjh@cpax.org.uk> - 2022-12-14 15:18 +0000
            Re: Another little puzzle "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-12-14 16:41 +0100
              Re: Another little puzzle "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-12-14 16:43 +0100
                Re: Another little puzzle Y A <angel00000100000@mail.ee> - 2023-01-09 16:33 -0800
              Re: Another little puzzle Richard Heathfield <rjh@cpax.org.uk> - 2022-12-14 16:13 +0000
        Re: Another little puzzle V <angleeeeeeee@mail.ee> - 2023-05-10 11:16 -0700
    Re: Another little puzzle Ǝ <angel0000000001000000000000@mail.ee> - 2022-12-30 05:59 -0800

csiph-web