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.uzoreto.com!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: Wed, 13 May 2020 12:36:11 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net XDUBH3Au5OHsyyDk6b9A4As+QQh6wfweP0DIFhqODHqts6q3Kv Cancel-Lock: sha1:rw6f722kKu6uYBhuHtFgA9oGhJM= 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:58672 Date: 2020-05-13T12:36:11+03:00 List-Id: On 2020-05-13 1:39, Jeffrey R. Carter wrote: > On 5/13/20 12:20 AM, Niklas Holsti wrote: >> >> I agree that it would be troubling. If you could find that statement, >> it would interest me. > > In https://lockdownsceptics.org/code-review-of-fergusons-model/ it says, > "the code produces critically different results, even for identical > starting seeds and parameters." While the review claims that as a general flaw, it then "illustrates" the claim by discussing the two cases I detailed, in particular the unexpected influence of the option controlling how the program "stores data tables". This was eventually traced to a difference in the way the program used the RNG, depending on this option, which then led to different PRN sequences, depending on this option. An error in the program, of course, but not non-determinism. For programs that use RNGs to drive simulations, a single extra RNG call, or a single omitted RNG call, will completely change the subsequent PRN sequence. This has no effect on the statistical properties of the results from many runs, but will of course change the results of the particular run in which the change occurs. > Initially it was claimed that this was > only true for multiple cores, but later that was retracted: "But > Edinburgh came back and reported that – even in single-threaded mode – > they still see the problem." It seems that some users (Edinburgh) reported that the results varied, and reported they were using multi-core mode. The authors of the program (Imperial) replied that result variations are expected in multi-core mode; this was of course a sloppy analysis of the problem, but not an unnatural one. When the users reported that the problem occurs also in single-core mode, depending on the "data table storage" option, the authors found and fixed the error. -- Niklas Holsti niklas holsti tidorum fi . @ .