That assumes you are sampling uniformly, and not in already saturated clusters. The doubling time is also not a known constant, as it depends on actions taken etc, and uncertainty in it will broaden the distribution.
Obviously, all this is basic statistics and should be known to epiodemiologists, who hopefully have some input to policies.
For large N_obs, this will maybe be less important as you're going to find the severe cases anyway, but the uncertainty is significant in the beginning stages, and it is unfortunately these stages where actions will have most impact.
What is important is that Dyson has quotes, but I'm not aware of any published work by him on the problem (by "published", I don't mean peer-reviewed, arXiv etc would be fine too). This means that he probably never really put his hands on the problem as a working scientist.
I'd rather remember Dyson for his significant contributions to physics, rather than for something he did not contribute to.
If the wealth created in a transaction is proportional to the size of the transaction, that sounds like it would increase the Gini coefficient. Most new wealth is created by transactions involving those with the most wealth, and redistributed to them. Probably simple to check in the simulation. Whether this is any good as a model for the real world is then a different question...
Fortran has language-level support for things important for numerical scientific computing (complex numbers, multidimensional arrays, etc.), and it has had them since the beginning in the 1950-60s.
The convenience is not really matched by C or C++, where similar features have been added much later by language extensions or 3rd party libraries, resulting to more complicated usage, fragmentation, and interoperability problems. Newer languages also have similar issues, so for the user base that uses Fortran, there's a lack of viable competitors.
The reported confirmed counts have grown by a factor of ~1.5 every day, fitting reasonably well with exponential growth. If this rate continued, in 35 days it would reach the world population. Obviously, in the real world the growth flattens out way earlier, from natural causes, and especially because of the attempts to confine it.
Comparing the total number of cases or deaths to flu outbreaks from previous years does not make much sense at this point, when the numbers are growing rapidly, but in a month they probably are easier to compare. Neither does comparing average counts per week, because the growth is not linear. The data for the progression of flu (or any other disease) outbreaks exists, and comparing to their growth rate would put it better in perspective. Regardless of armchair analysis, the WHO declaration means it's something requiring unusual action, which flu is not.
The approach of doing the transition slowly over many years maybe was a mistake here, and another thing making it harder seems to have been little support from the top of the project.
I ported two projects with ~200000 Python-SLOC (about the same size as Mercurial according to sloccount) back in the early 3.x days. Doing this via more or less flag-day conversions within a few months, converting the codebases first to 2to3-able subset, and as a second step later on dropping 2to3 via common dialect of Python 2/3 with six, was not very painful in the end.