numpy compatibility

[abotas]

This will give an error in numpy 1.11 and not in numpy 1.12
np.random.normal(scale=[.2,0,4])

I believe those of us that ran
source manage.sh install_and_check X.Y
before Jan 15th have v1.11 and those who ran it after have v1.12

At the moment, this means Travis-Ci will show that Anastasia passes all her tests, but if someone who started working in IC before Jan 15th tries to fetch my branch and test it, they will get this error:

ValueError: scale <= 0
I can write some uglier code to accommodate the old version of numpy, or do we all want to use the new version of numpy? Is this a symptom of a larger issue? Or are we all just responsible for continually updating our packages used by our minicondas?

[gonzaponte]

This:

np.random.multivariate_normal(np.zeros(3), np.diag([.2,0,4]))

should work in any version. Does it provide the same results?

[abotas]

That line of code looks like it will work, but do we want to make sure we are all using the same versions of all the packages?

Otherwise when we collaborate I think we risk running into an error that like
ValueError: scale <= 0
without having any idea what is going on

[jmbenlloch]

We need to decide what do we want to do with packages versions and this is probably related to #134.

Now @abotas has found this simple problem, requiring few lines of code to work in both numpy versions. But the situation is that each developer has a different set of packages versions depending on when the software was installed, while Travis is always getting the latest one available since we do not impose any version restriction in our conda environment.

In the future more complicated problems could arise due to versions mismatch. I think we should define somehow all packages versions so all developers work with the same libraries. Whatever we might decide could potentially solve also #134 (or maybe not). It is not clear to me yet how we can do this, I'll give it a thought, ideas are welcomed.

[jacg]

Yes, it is definitely related to #134.

In the short term I think we could do with a new function in manage.sh which updates the env to the latest available packages, so that we agree with Travis.

I don't think there's a need to stay compatible with old versions of these packages.

I think that this, or rather #134, is important, but not of the highest urgency.

The new manage.sh function could be low-hanging fruit, in which case we should pick it right away.

[jjgomezcadenas]

Since this is fully correlated with #134 I think we can close it