-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
estimateAlpha #460
estimateAlpha #460
Conversation
Related to #417 |
I am tending to think that we should combine all these estimateXXX functions into a single estimateAlpha function as your PR suggest. The other estimateXXX functions could be turned into internal functions to simplify the interface. That estimateAlpha function can then have rarefaction as optional argument (including the user-specified rarefaction depth; by default the lowest read count among the samples). Things to consider:
If unclear, we can discuss more. I have some further comments in mind after the next PR draft on this. |
The function has to be changed into estimateAlpha, which then includes rarefaction as an optional argument |
An idea: the method name (like "shannon") could also say "diversity", then the function would return all "diversity" indices and if one asks for "dominance" then those etc (richness / evenness / diversity / dominance / rarity are the options and the indices are listed in those corresponding functions now). If no method is specific, then all indices would be returned by default. |
I think this is not the best way to implement this. Better way is to keep those estimateDiversity.R and other files and just add estimateAlpha.R with estimateAlpha functionality (remove documentation from necessary places) The problem with moving all the code to one file is that it is a nightmare for someone that tries to check what has been changed. It looks like everything has |
I agree. The old and extensively tested functions can be kept as is. They should be just converted into internal functions that are not exported (as I already explictily suggested in the opening statement of this issue), and then called from a wrapper called |
Alright, I misunderstood the comment I will make the changes. |
Always aim at minimal and straightfwd changes unless otherwise agreed. If you could update this PR accordingly that would be great! |
I didn't understand, could you please explain more. |
Do you mean smt like this?
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Some comments added. Perhaps TB has more
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
COding style should more or less match between functions even though we have multiple developers. For example there is no many comments
I think this is good to go. @ake123 Do you have time to check that there are necessary unit tests (there might be already)? Check Leo's comments about testing whether rarefying was disabled (n.iter = NULL and n.iter = 0) |
Sure I can check that
|
Fixed some issues and updated documentation. Would be nice to have someone else's thoughts (if everything works) but I think this is good now |
One last thing: I changed If someone is against this change, I'm happy to discuss about this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
It seems the unit test have been updated with niter=NULL, niter=0 as default and with no errors. |
@ake123 Can you check that OMA and mia* packages are updated? |
Yes sure! Should I add section addAlpha in the diversity section? |
Initial draft implementation.