Lift "No Compatibility Guarantee" about ng-numpy-randomstate

[bashtage]

The no guarantee is my reaction to , IMO, NumPy's excessively stringent compatibility guarantee for its PRNG (commitment to never change, ever, irrespective of improvements). This has created a lot of difficulties with adding better algorithms for generating random numbers (e.g. the improved normal generator that is here, which is ~4x faster than NumPy with the same underlying PRNG). I think this is the wrong choice, and it seems a little strange in an OSS world where one can simply use a requirements file to specify specific versions, which will always produce identical results.

I think one way forward would be to include version-specific RandomState objects whenever there is a change. For example, if there was a change in, say 1.12, then the main RandomState object would be the current one, but there could be a RandomState object called, e.g., RandomState111 that would be identical to the 1.11 version. This would be pretty maintainable since one can simply use inheritance to override updated methods,

class RandomState(object):
    def random_nums(...):
        # new algo

class RandomState111(RandomState)
    def random_nums(...):
        # old algo

The exact interface for getting the old version would be something like

rs = RandomState(version='1.11')

which would then return the RandomState from that version, which might be the current one if there are no breaking changes.

[gdementen]

Version-specific RandomState objects seem a great solution to me. As long as there is some easy way to generate the "old version" numbers, that's good.

I fear that "simply use a requirements file to specify specific versions" might not be that simple in the long run: wouldn't there be cases where old versions of ng-numpy-randomstate would not be installable with more recent versions of numpy, cython, pip, or whatnot? This means you would have a cascade of other libs you could not upgrade which is not desirable.

[bashtage]

Ideally requirements files are highly specific so that the version of Python, NumPy, SciPy, would all be specified. This is the only way to know you are going to have code that will always work and get the same algorithms. This said, you should get mostly similar even from different algos, within numerical limits. PRNGs are a different beast and different algos only preserve results in a probabilistic sense -- that is, you could get random numbers from the same distribution, not the same random numbers.

I have started a bit of work on this by adding a version to the state. More investigation is needed to figure out how exactly to return a different class in Cython than the one requested.

Kevin

[gdementen]

Ideally requirements files are highly specific ...

That's precisely what I would like to avoid. I would like to be able to continue adding new features to my application, some of which require to use features of newer libraries (numpy or otherwise) AND be able to reproduce results from earlier versions of my application. If users of my app cannot compare the results they obtain using newer versions of my app to those of earlier versions, some of them will never upgrade. If I can simply tell them: "if comparing with older versions is important to you, set this variable to the name of the older version", that seems very reasonable. If however, every two versions of my app breaks their comparisons without any way for them to fix that, that is likely to piss them off.

PS: I just want you to understand why I would like this feature, but I don't mean to put any pressure on you.

[bashtage]

I'm going to close this. I'm currently working on what will likely be the real next generation NumPy API which will separate the core PRNG from the functions which transform random integers to distributions or do other things. This second structure will maintain backward compat while allowing progress with new algorithms.