undefined Le mer. 20 mars 2019 à 21:39, Alex Herbert <alex.d.herb...@gmail.com> a écrit : > > > > > 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.]
Correcting: The second argument (number of threads) is still needed. > >> > >> 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. If the user forgets to supply one, the program outputs one, and stops; then the user reissues the command? > > 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? Or this one: https://picocli.info/ > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
