#4 confusion over generator names

[G. Jones]

In version 0.90 RNG_test and RNG_output, some of the generators mentioned
in documentation don't exist, or more likely exist under other names. An
example is lcg48_16 . There is no obvious way to find out which generator
names are implemented. For instance there are some generator names which
are implemented, but don't occur in plaintext in either the source or the
binary. Correct documentation would be nice. But perhaps easier and nicer,
a program option to print a list of valid generator names. (After all, the
program probably knows these things better than the documentor?)
(BTW thanks for this project. I like some of the generators. I like the tests
even more.)

Yes, it's an issue, and I don't have an easy fix. The main source of the problem is that some non-recommended RNGs are implemented as parameterizations of general case RNGs. lcg48_16 (renamed to lcg16of48 in 0.91) is actually lcg64_16_varqual(32) (or lcg16of64_varqual(32) in 0.91) or something like that.

Possibly I should list it as that in Test_results.txt, but that would make it even less clear what the RNG actually was conceptually in the results listing. Ideally I'd have some code that could recognize names like lcg48_16, parse them, and adapt it to the correct underlying RNG and parameters, but that would be a bit of a pain considering how many variable quality non-recommended RNGs there are.

Possibly the best compromise would be to leave it as it is, but add a note to Test_results.txt near the LCG section describing the issue, which primarily effects LCG-like PRNGs.

New plan for 0.91:
instead of lcg8of64_varqual / etc it will now be:
lcg(output_bits,total_bits)
which will intelligently switch it's implementation among the various general lcg algorithms included. Note that these names are only for text->RNG (mainly command line parameters) - if you ask an RNG its name it already produces names consistent with those listed in Test_results.txt (lcg16of48 etc in 0.91 or lcg48_16 in earlier versions) and that will remain unaltered. Which creates confusion since the name to specify it on the command line parameter does not match its name exactly, but there will be a note added to Test_results.txt to clarify that.
edit: okay, changing the name in the output from lcgY_X / lcgXofY to lcg(X,Y) so it matches the input. It seems less intuitive to me, but consistency is probably more important.

Likewise for xlcg, clcg, and cxlcg. However the other varqual PRNGs remain unchanged, for now.

In recent versions (0.93, not sure about 0.92), both the abstract factory and the get_name method use the new naming scheme, as does Test_results.txt, for every RNG. This means that the implementation (and its actual parameters) may be a littler harder to track down, but at least everything at the higher abstraction layer should look consistent now. If Test_results.txt refers to an RNG to as "lcg(16,56)" then you can ask for an RNG by that name and it will return the correct RNG, and if you ask that RNG for its name it will indeed return "lcg(16,56)".

There is one notable exception at the moment: Test_results.txt refers to RNGs named as parameterizations of "bblcg", and asking for a parameterization of that will work fine. However, if you use get_name on the resulting RNG, it will tell you that it is a "bigbadlcg" instead. Basically, bblcg is an alias for bigbadlcg, both will work interchangably anywhere an RNG name is expected but get_name returns the longer name while Test_results.txt refers to the shorter name (to fit it in to the name column more easily).

I think this is about as good as it gets, I'm going to mark the issue as resolved.