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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:ac8:2965:: with SMTP id z34mr26493322qtz.44.1589377955668; Wed, 13 May 2020 06:52:35 -0700 (PDT) X-Received: by 2002:aca:57c4:: with SMTP id l187mr28291986oib.155.1589377955301; Wed, 13 May 2020 06:52:35 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!fdn.fr!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 13 May 2020 06:52:35 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=47.185.215.60; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.215.60 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Not to incite a language war but apparently the Corona lockdown was based on 13 year old undocumented C-Code From: Optikos Injection-Date: Wed, 13 May 2020 13:52:35 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:58677 Date: 2020-05-13T06:52:35-07:00 List-Id: On Wednesday, May 13, 2020 at 4:36:15 AM UTC-5, Niklas Holsti wrote: > 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,= =20 > >> it would interest me. > >=20 > > In https://lockdownsceptics.org/code-review-of-fergusons-model/ it says= ,=20 > > "the code produces critically different results, even for identical=20 > > starting seeds and parameters." >=20 > While the review claims that as a general flaw, it then "illustrates"=20 > the claim by discussing the two cases I detailed, in particular the=20 > unexpected influence of the option controlling how the program "stores=20 > data tables". This was eventually traced to a difference in the way the= =20 > program used the RNG, depending on this option, which then led to=20 > different PRN sequences, depending on this option. An error in the=20 > program, of course, but not non-determinism. >=20 > For programs that use RNGs to drive simulations, a single extra RNG=20 > call, or a single omitted RNG call, will completely change the=20 > subsequent PRN sequence. This has no effect on the statistical=20 > properties of the results from many runs, but will of course change the= =20 > results of the particular run in which the change occurs. >=20 > > Initially it was claimed that this was=20 > > only true for multiple cores, but later that was retracted: "But=20 > > Edinburgh came back and reported that =E2=80=93 even in single-threaded= mode =E2=80=93=20 > > they still see the problem." >=20 > It seems that some users (Edinburgh) reported that the results varied,=20 > and reported they were using multi-core mode. The authors of the program= =20 > (Imperial) replied that result variations are expected in multi-core=20 > mode; this was of course a sloppy analysis of the problem, but not an=20 > unnatural one. When the users reported that the problem occurs also in=20 > single-core mode, depending on the "data table storage" option, the=20 > authors found and fixed the error. On which date did they fix the problem? Before or after governments acted = on the miscalculations?