Re: Do you think 12:00pm is noon or midnight?

On 12 Jul, 09:31, "Paul J Kriha" <paul.nospam.kr...@xxxxxxxxxxxxxxx>
wrote:
"Harlan Messinger" <hmessinger.removet...@xxxxxxxxxxx> wrote in message

news:5fk5h0F3cr2bpU1@xxxxxxxxxxxxxxxxxxxxx

Seán O'Leathlóbhair wrote:
Does 12:00 necessarily mean the period 12:00:00 to 12:00:59.999...
rather than 11:59:30 to 12:00:29.999...? In other words, does a time
in whole minutes necessarily represent a truncation rather than a
rounding of the true time?

Are you sure you didn't mean time just after 11:59:30 to 12:00:30 exactly.. :-)

We are in danger of wandering too deep into maths here. If you read
my 999... as an endless sequence of 9s then it will be the same as
12:00:30. What I was trying to informally indicate was the range
11:59:30 <= time < 12:00:30 so that the lower limit was included but
the upper was not. With the most common form of rounding, 12:00:30
would go to 12:01.

Suppose it's 2:04 or so, and you have a digital clock reading hours and
minutes that you want to synch with a source that shows the time in
seconds. I think most people would try to arrange it so that 2:06 on the
clock kicks in when the source shows 12:06:00 rather than when it shows
12:05:30.

Hey, rounding is more PC.
Unfortunately it leads to vicious wars over the methods of rounding.


It can matter with money, fractions of a penny or cent can add up to a
significant amount in a bank's accounts.

However, in this case, I just wanted to point out that for an analogue
device, rounding was more likely than truncation. For example, when
the two hands of my watch are both on 12 (as far as I can tell) then
the time is close to 12:00 but may be slightly before as well as
slightly after. With a digital device, it would as Harlan says, 12:00
or slightly after but not before.

--
Seán Ó Leathlóbhair

.

Relevant Pages

  • Re: Rounding errors
    ... It maintains the average of the infinite precision original ... With enough digits the average is close enough to ... Rounding maintains this with an average of 0.500. ... >It only 'pushes it upwards' with respect to how much truncation ...
    (comp.lang.cobol)
  • Re: Rounding errors
    ... Rounding maintains this with an average of 0.500. ... It only 'pushes it upwards' with respect to how much truncation ... You continue to say 'rounding error' when applied to an average. ... If the set of infinite precision reals adds up to the same as the set ...
    (comp.lang.cobol)
  • Re: Rounding errors
    ... How does the rounding operation know what truncation came ... I am suggesting that you may get a different expectation 'with ... > by FACTS, ...
    (comp.lang.cobol)
  • RE: [OT] Rounding v Truncation, was: Re: Platform Support vs.
    ... Subject: Rounding v Truncation, ... > If you don't exploit EXPLICIT conversion then you had better know the ... If you have received the email in error, please notify TransGrid ...
    (comp.os.vms)
  • Re: Rounding errors
    ... digits then the average is _NOT_ 0.500. ... Rounding of the original set of long numbers, ... When you round the numbers to two digits what existed beyond the 3rd ... so the truncation doesn't matter. ...
    (comp.lang.cobol)