Test of refactored classes

[macroevolution]

Test of refactored classes

[drabosky]

This sounds exciting! I unfortunately won't have time to work on this in the very near future. But I think it is important to test carefully, since we know the program works at the moment.

We should discuss setting up some general protocol (or a set of trial datasets) that we come back to for performance benchmarks & general tests for major updates like this.

On Dec 5, 2013, at 1:49 AM, Carlos Anderson wrote:

I've been doing a lot of restructuring of classes to avoid code duplication. I've been working in a separate branch, called "mcmc," which I've uploaded. I'd appreciate it if anyone could test the program for correctness before I merge the branch with the master. Please test the program on a variety of data sets and verify that the results make sense. You won't be able to compare the results with a previous program using the same seed because the restructuring has caused the random number sequence to be different.

To download the mcmc branch, do a "git pull", then "git checkout mcmc". To go back to the master, do "git checkout master".

Thanks!

—
Reply to this email directly or view it on GitHub.

[jeffjshi]

So for doing this testing do we make a new executable from the mcmc branch?

[drabosky]

I suggest we first come up with an explicit protocol for testing this. We need a series of examples that we can routinely come back to for validating performance etc. I've talked a little with Carlos about this but we haven't actually set something up.

On Dec 6, 2013, at 4:42 PM, jeffjshi wrote:

So for doing this testing do we make a new executable from the mcmc branch?

—
Reply to this email directly or view it on GitHub.

[redcurry]

Yes, we need to come up with good tests. But to try out the mcmc branch, you need to checkout that branch, make clean and then make again to compile the new code. Remember that when you "checkout" a branch, git replaces the contents of your current directory with that the contents of branch, except those files that are not being tracked---like "build." If you checkout mcmc and you had a build directory, the excutable there will be of the master branch, not the mcmc branch. That's why you need to make again.

[drabosky]

My git knowledge has not gotten to this point yet where I am comfortable with this at all, but we need to be very sure that there are no accidental merges until this is ready, and no one should do this without checking with Carlos or me.

I don't want to sound paranoid about this, but some of you remember that linux was installed on the ummzm-drabosky lab machine without checking with me (I was in Australia), and it gave me serious headaches (and a few days of delays) when I tried to access my data on the OSX partition. There's still a boot error on that machine that needs fixing as a result of that, if I recall correctly.

On Dec 6, 2013, at 5:32 PM, Carlos Anderson wrote:

Yes, we need to come up with good tests. But to try out the mcmc branch, you need to checkout that branch, make clean and then make again to compile the new code. Remember that when you "checkout" a branch, git replaces the contents of your current directory with that the contents of branch, except those files that are not being tracked---like "build." If you checkout mcmc and you had a build directory, the excutable there will be of the master branch, not the mcmc branch. That's why you need to make again.

—
Reply to this email directly or view it on GitHub.

[redcurry]

Good point. Some of us should meet to discuss how to proceed with developing some tests. I think users would also like to see the results of these tests, whether it's for benchmarking efficiency or to show them that our software is stable.

[jeffjshi]

That's something I'd love to meet and help with since I'm a bit outpaced in the R department for now.