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:a05:6214:bc5:: with SMTP id ff5mr10187075qvb.118.1591915398299; Thu, 11 Jun 2020 15:43:18 -0700 (PDT) X-Received: by 2002:a05:6830:14c2:: with SMTP id t2mr8315363otq.5.1591915397957; Thu, 11 Jun 2020 15:43:17 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 11 Jun 2020 15:43:17 -0700 (PDT) In-Reply-To: <6bd5d971-6101-4e9e-aac3-7c5c2a8390abo@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=114.134.6.125; posting-account=g6PEmwoAAADhFsmVm6Epjviaw4MLU0b5 NNTP-Posting-Host: 114.134.6.125 References: <6bd5d971-6101-4e9e-aac3-7c5c2a8390abo@googlegroups.com> 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: Anatoly Chernyshev Injection-Date: Thu, 11 Jun 2020 22:43:18 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 7061 X-Received-Body-CRC: 3362943045 Xref: reader01.eternal-september.org comp.lang.ada:59050 Date: 2020-06-11T15:43:17-07:00 List-Id: Hi Olivier, Thank you for your generous offer. However, this model is an (unorthodox) a= cademic exercise, which draws attention of very few people. So, the develop= ment of a UI will be unwarranted waste of time (on my side in any case). As the current pandemics draws to a close, I probably will make yet another= updated forecast in the next week or so, and be through with it. This is n= ot the main application area in our company anyways. If anything, I'd rather see the GUI implemented in GNOGA. So that the softw= are would automatically download the countries statistics from a WHO server= , and update the graphs accordingly on a web page. That would require a maj= or overhaul of my current code though... That's probably what we can do for the next pandemic, due in the next 8-10 = years (according to the recent history). If you don't mind I'll take a rain= check for your proposal. Thank you again. Cheers, Anatoly On Friday, June 12, 2020 at 5:28:42 AM UTC+12, Olivier Henley wrote: > On Saturday, May 16, 2020 at 1:01:05 AM UTC-4, Anatoly Chernyshev wrote: > > "Clowns will dominate the pandemic-forecasting domain..." > >=20 > > I like that one... > >=20 > > Oh dear, you've lured me out. As a person who just published a Covid-19= forecasting model programmed in Ada, I can't stay away from this heated co= nversation. > >=20 > > There are so many concerns raised about scientists doing their rookie p= rogramming without resorting to professionals, so I don't even know where t= o start. > >=20 > > First of all, we are curious bunch, and learning something new (like pr= ogramming) is always fun. Second, in scientific programming the chance that= someone in power will lock down a country based on the output of your prog= ram is negligible (certainly it wasn't on the radars 13 years ago). Third, = fourth...=20 > >=20 > > To make a long story short, for the experiment's sake, is there anyone = willing to review my code? It's not a marvel of Ada programming, it just wo= rks. > >=20 > > Yet it's quite short - I went from the model's formulation, programming= , testing, data acquisition, manuscript writeup in a matter of a fortnight. > >=20 > > If the review is useful, in terms that it helps to produce more accurat= e forecasts or identifies a drastic flaw in the code, I would be more than = happy to do a revised version of the manuscript in a coauthorship with the = reviewer(s). Or even go for a peer-reviewed publication when dust settles. > >=20 > > The model forecasts are here: > > April 10th: https://xph.co.nz/temp/album/ > > May 12th: https://xph.co.nz/temp/album2005/ > > Some technical details: https://xph.co.nz/index.php/covid-19-progressio= n-model/ > > The model description: https://www.medrxiv.org/content/10.1101/2020.04.= 03.20052985v1 > >=20 > > This is not an epidemiology-based model (so you don't have to be one). = Rather, it's a phenomenological one. It can predict what will happen, but c= an't (yet) say why this will happen. A contribution on the model is welcome= d too. > >=20 > > The code is not published (since I didn't expect anyone would care), bu= t I'll do it once there's interest. > >=20 > > If keen, please write to me directly: a~at~xph~dot~co~dot~nz > >=20 > > Anatoly >=20 > Hi Anatoly, >=20 > Maybe, if you agree, are interested, and your code is not a nightmare to = work with (refactor to expose things needed to drive it in UI), I could fin= d time to code a graphical tool for it. Please consider what I did for Gaut= ier's work (the screenshot does not show but everything is dynamic and the = export to .csv works like a charm). It took me half a day learning the qt5a= da binding on the fly: >=20 > https://github.com/ohenley/covidsim >=20 > My plan would be quite straightforward; in loose Model-View-Controller te= rminology: >=20 > 1. Take your 'engine/simulation' code, make a git repo, publish it as a f= ork on GitHub. No fork this time if your code is not on GitHub already. Wou= ld be best for you to own it (create a Github user, upload your code, etc. = But if you are not up to that, I will take care of it. You can collaborate = on my repo with proper credentials explicitly set anyways.) >=20 > 2. I refactor your code to push at the frontier, only parameters and simu= lation outputs to be driven/drive the UI layer. I do not touch the simulati= on calculations, this is not my expertise, and if the engine internals brea= k I want *you* to fix it. I only/mostly touch on the inputs and outputs of = those computes for them to become parametrizable externally. (This layer is= the Model, your know-how.) >=20 > 3. I create the visual layer, expose the parameters and behavior we want = for the tool. (This layer is the View and Controller). I make another git r= epo out of this. This layer owns your layer to 'talk' with it. >=20 > We end up we 2 codebase/repos, like that, you and other scientists can fi= x the 'engine' without me knowing/caring because you touch on the 'model' l= ayer only. >=20 > Anytime you come up with new features/computations etc working, you tell = me, I repeat steps 2. and 3. to have the feature exposed in the visual tool= . >=20 > Let me know what you think if you are interested. I will forward this to = your mail too. >=20 > Olivier >=20 > p.s: If your codebase is huge/complex/lot of features maybe we can start = to expose only a subset in a tool. From there, because it's available throu= gh github, people in this thread could collaborate (clone, edit, push)