From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Not to incite a language war but apparently the Corona lockdown was based on 13 year old undocumented C-Code Date: Tue, 12 May 2020 22:16:18 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net H97A5oTwZP1aauWwXZLM5wbKJMZ5NuRxq4C5DTRgVJqzM8hQJ7 Cancel-Lock: sha1:ak+rS+cm0Bs8z49NAUN1umriWR8= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 In-Reply-To: Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:58660 Date: 2020-05-12T22:16:18+03:00 List-Id: 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 . @ .