[HECnet] How long has your 20 been up?

[Thomas DeBellis]

What has repeatedly struck me over the years is how many systems 
programmers can not do anything beyond basic arithmetic .

My favorite example is computing future dates using the 36 bit time of 
date format.  Briefly, this is stored as two 18 bit halfwords, the left 
halfword being the number of days since something 1858, the right 
halfword being a fixed point fraction of a day.  That unit is something 
that I will call a time of day tick.  If we assume 24 hours a day, then 
one tick is 1/(2^^18 ) times that number of seconds or 0.329589844 seconds.

This is almost, but /not quite/ a third of a second.  You would be 
surprised how much code there is that converts to seconds simply does an 
integer divide by three instead using a proportion and rounding.  A 
second is actually second is a little more than three TOD ticks, 
3.034074074, so depending on how much elapsed time you are talking 
about, you will get an increasingly wrong answer.

Kermit-20 did this to estimate transfer times until I noticed it and 
fixed it.  Consider 2,560 time of day ticks.  Dividing by three yields a 
quotient of 853 seconds whereas the actual value is closer o 844 
seconds, a difference of nine seconds.  For a transfers taking over a 
day and a half, the difference is over _10,000_ seconds.  Such weekend 
overnight dial-up transfers actually did happen with some regularity.

The aging code in Quasar to determine job priority has a similar bug and 
gets the wrong answer, although another factor makes the answer 
drastically, incomprehensibly wrong. This was one of the very first 
things I fixed in QSRADM and SPR'ed to DEC, maybe around 1980 or 1981.

It's /*still*/ not fixed in the standard DEC Tops-20 distribution, 
although later PANDA versions may have it (early ones didn't).  I have 
yet to look at the Tops-10 Galaxy version.

It really annoyed me to fix it on /every/ single release, only to never 
see it show up in the standard release...  I mean, when I was at 
Marlboro, I was in the Galaxy group (2116).

> ------------------------------------------------------------------------
> On 1/18/22 7:48 PM, Johnny Billquist wrote:
>
> By then, we probably also need to look at/revise how we compute leap 
> years... It's well known that the current algorithm will slowly get us 
> out of phase again...
>
>   Johnny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sonic.net/mailman/private/hecnet-list/attachments/20220120/ee95ae97/attachment.htm>