brettc
commented
8 years ago I vote for option 1 as well.
The python / cython code for tigger is available in a separate repository here: https://github.com/brettc/tigger in any case. This would be a good starting place for future Tiger/python projects.
A comment though: I think the reason to remove it is that the entropy stuff works better. I don't think a good reason to remove it is because: "users find compiling C hard". We already distribute compiled C code (raxml and phyml). If we didn't have the entropy solution, we'd simply have to distribute some more compiled c code (which, of course, would make our lives more difficult).
I should add that compiling tigger is, in fact, very easy. You just need to right dependencies installed. The hard bit is making sure you have all the right dependencies installed (ie. the reason Anaconda is so good).
Cheers, Brett
On 19 May 2016, 9:55 AM +1200, roblanfnotifications@github.com, wrote:
Hey@brettc(https://github.com/brettc)@pbfrandsen(https://github.com/pbfrandsen)@wrightaprilm(https://github.com/wrightaprilm),
Here's something to figure out. Right now we have THREE implementations of TIGER, and this is confusing. They are:
Paul's TIGER code in C Brett's TIGGER code in C Paul's pure python TIGER code
Right now these can all be called from the commandline with options like--kmeans tiger`or--kmeans fast_tiger``. It's kinda confusing. My question is, what is the best thing for users here? We don't officially support TIGER for DNA or protein any more (entropy is just as good, and ~infinitely quicker), but TIGER might still be useful for morphology datasets, which are much smaller.
Here are two options, let me know which you prefer, or if there are others you think are better.
Option 1
Delete all C code, retain Paul's pure python implementation, and only have TIGER work with morphology (these datasets are small, and pure python is OK here). If users call --kmeans tiger from the commandline with DNA or protein, they get back an error.
Pros: v. simple for users, and for us to maintain. Cons: users don't get to do TIGER rates on DNA/Protein any more (do they care?)
Option 2
Retain one of the C implementations (in which case Brett/Paul need to be willing to maintain it if there are bugs, which of course there aren't, and also answer inevitable installation/compilation questions on the forum), and use that for DNA/Protein, but pure python for morphology (so that we avoid problems in the most common use case).
My vote is forOption 1. Because it's the simplest, and doesn't require users to ever compile C code, which is I think a step too far for most users, and will just put people off. We can keep the code in place for running fastTIGER and TIGGER, but just remove the options to do so, and mentions of them in the docs.
Thoughts?
R
— You are receiving this because you were mentioned. Reply to this email directly orview it on GitHub(https://github.com/brettc/partitionfinder/issues/103)
roblanf
wrightaprilm
pbfrandsen
cmayer
Hey @brettc @pbfrandsen @wrightaprilm,
Here's something to figure out. Right now we have THREE implementations of TIGER, and this is confusing. They are:
Right now these can all be called from the commandline with options like
--kmeans tigeror--kmeans fast_tiger. It's kinda confusing. My question is, what is the best thing for users here? We don't officially support TIGER for DNA or protein any more (entropy is just as good, and ~infinitely quicker), but TIGER might still be useful for morphology datasets, which are much smaller.Here are two options, let me know which you prefer, or if there are others you think are better.
Option 1
Delete all C code, retain Paul's pure python implementation, and only have TIGER work with morphology (these datasets are small, and pure python is OK here). If users call --kmeans tiger from the commandline with DNA or protein, they get back an error.
Pros: v. simple for users, and for us to maintain. Cons: users don't get to do TIGER rates on DNA/Protein any more (do they care?)
Option 2
Retain one of the C implementations (in which case Brett/Paul need to be willing to maintain it if there are bugs, which of course there aren't, and also answer inevitable installation/compilation questions on the forum), and use that for DNA/Protein, but pure python for morphology (so that we avoid problems in the most common use case).
My vote is for Option 1. Because it's the simplest, and doesn't require users to ever compile C code, which is I think a step too far for most users, and will just put people off. We can keep the code in place for running fastTIGER and TIGGER, but just remove the options to do so, and mentions of them in the docs.
Thoughts?
R