Re: Not to incite a language war but apparently the Corona lockdown was based on 13 year old undocumented C-Code

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2020-05-12 0:55, Jeffrey R. Carter wrote:
> On 5/11/20 10:27 PM, Niklas Holsti wrote:
>>
>> I've seen a somewhat longer and better review of this code, but I 
>> didn't save the link (sorry). The following points were criticized IIRC:
> 
> I saw the interpretation of the review that Gautier linked to at 
> https://lockdownsceptics.org/code-review-of-fergusons-model/. From the 
> site name we can conclude that this is not an unbiased interpretation.
> 
>> Moreover, the code is deterministic if executed on a single core 
>> (after some errors were corrected which seemed not to be unusually 
>> alarming).
> 
> It seems clear that the code that was executed to create the predictions 
> was not deterministic on a single core.

The first of the two cases of single-core "non-determinism" described 
and bewailed in the "review" is that the time evolution of the predicted 
epidemic is different depending on the value of a program option -- 
whether the "network" is created anew, or reused -- that should not 
affect the result. No actual non-determinism is claimed in the review, 
just that the epidemic reaches large infection rates sooner for one 
option value than for the other. It seems that the code was using the 
PRN generator slightly differently in the two cases, resulting in 
different PRN sequences.

The program models exponential growth, so the simulated time evolution 
is clearly very sensitive to the small-number statistics (few initial 
infections) at the start of the simulation, which is one reason why one 
should run several simulations. Looking at the predicted growth curves 
for the two option values, they have the same shape and height but are 
just shifted slightly in time.

The same effect is clearly seen in actual data from Covid-19 infections 
in different countries. Initially, newsmedia used to align the starting 
points of the curves at the point of the first detected infection or 
first death, which is clearly a statistically unreliable indication of 
the real starting point, and so the main growth of infections often 
started after different delays in different countries. When the curves 
are aligned at the point, say, of 10 recorded deaths, the differences 
between the curves are much smaller.

The second case of single-core "non-determinism" mentioned in the report 
is that the program gave different results on different computers and 
compilers. This difference is explained (in the bug report) by the 
different compilers using different floating-point instructions: either 
a merged multiply-add or separate multiply and add, resulting in 
different roundings, a well-known and common issue in floating-point 
computations. Such issues are often addressed by running several 
computations with slightly fuzzed inputs or intermediates, which occurs 
naturally if this program is executed several times with differnt PRN 
sequences. Again not what I would call real non-determinism.

In the review, the sentence that speaks of the original "15.000 line 
file" links to a tweet by John Carmack, who "helped a little" on the 
updates to the code. I quote this tweet series 
(https://twitter.com/ID_AA_Carmack/status/1254872369556074496):

"Before the GitHub team started working on the code it was a single 15k 
line C file that had been worked on for a decade, and some of the 
functions looked like they were machine translated from Fortran. There 
are some tropes about academic code that have grains of truth, but it 
turned out that it fared a lot better going through the gauntlet of code 
analysis tools I hit it with than a lot of more modern code. There is 
something to be said for straightforward C code. Bugs were found and 
fixed, but generally in paths that weren't enabled or hit. Similarly, 
the performance scaling using OpenMP was already pretty good, and this 
was not the place for one of my dramatic system refactorings. Mostly, I 
was just a code janitor for a few weeks, but I was happy to be able to 
help a little."

I would call that a rather positive evaluation of the code quality, even 
if it shows some prejudice against Fortran and machine translations.

-- 
Niklas Holsti
niklas holsti tidorum fi
       .      @       .