> On 20 Mar 2019, at 18:22, Gilles Sadowski <gillese...@gmail.com> wrote: > >>> [...] >>> Perhaps the "RandomStressTester" should be made more flexible >>> and, instead of a hard-coded "GeneratorsList", accept a list of "enum" >>> identifiers. e.g. a list (ASCII file) like: >>> MT 3 >>> MT_64 3 >>> SPLIT_MIX_64 3 >>> [etc.] >>> where the second columns indicates how many runs to perform for >>> this type of RNG. >>> [A (mandatory) flag specifying this file would replace the first 2 >>> command-line arguments.] >> >> That would be nice. >> >> But: >> >> 1. The GeneratorsList class allows a user to use another list that is on >> the Java classpath and test their own generators provided by that list. >> That is if I understand how Java can build things using reflection. The >> likelihood of ever needing to do this is ... ? (very small) > > And they could still do that if they add to the "RandomSource" list…
Yes. So no need to worry about what others will do and just support named enums in RandomSource. > >> >> 2. The GeneratorsList class can be auto generated from the enum > > There could be a provided input file, updated whenever "RandomSource" > is. > One advantage is they we could slightly expand the format to allow e.g.: > > TWO_CMRES 3 > TWO_CMRES() 3 > TWO_CMRES(1,2) 3 I had wondered about supporting additional arguments to the RandomSource.create method. Currently we only need to support Integer but support for Integer, Long, Float, Double can come from using the canonical form, e.g. 0, 0L, 0f, 0.0. Perhaps just jump hurdles when needed. An easier approach would be to hard code the handling of TWO_CMRES_SELECT to know the values inside the parentheses are two ints. > >> I suppose it could be updated to require an input text list (as per your >> example) but if called with no arguments it can print out a default text >> list using the order of the RandomSource enum. >> >> Thus it should not need to be modified if more generators are added. > > I'm not sure I understand here. If the program only needs to support RandomSource then it can easily enumerate RandomSource and print out an example input file. Then there is no need to provide an input file for the program since it can write a default one. It would have to know to handle TWO_CMRES_SELECT with arguments. But since it is only one case this is easy to support. Q. Since this is in examples can it depend on another project, e.g. Commons CLI? It would make the parsing of arguments easier for this and the data dumper program. I’m not sure how recent Commons CLI is. The homepage states "a freshly designed and not backwards compatible CLI 2 was created in 2004, but never finished or released." But it looks like it has all the functionality to parse the type of arguments we are discussing for these programs. Alex > > Gilles > >>> [...] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
