Moving things from CodonMolEv, and adding some convenience functions

[murrellb]

No description provided.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 15 lines in your changes missing coverage. Please review.

Project coverage is 37.02%. Comparing base (6930e8d) to head (4662d91).
Report is 116 commits behind head on main.

Files with missing lines	Patch %	Lines
src/core/simple_interface.jl	0.00%	9 Missing ⚠️
src/core/sim_tree.jl	0.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #44      +/-   ##
==========================================
+ Coverage   31.23%   37.02%   +5.78%     
==========================================
  Files          30       42      +12     
  Lines        2126     2774     +648     
==========================================
+ Hits          664     1027     +363     
- Misses       1462     1747     +285     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nossleinad]

I think "partition_inds" is a better name than "partition_list", the kwarg we use for the algorithms. I'd also like to point out that your default for "partition_inds = 1" is not the same as "partition_list = 1:length(tree.message)". These default values need not be the same in the future but I do think we should replace all instances of "partition_list" with "partition_inds".

[murrellb]

I think "partition_inds" is a better name than "partition_list", the kwarg we use for the algorithms.

Yes I had the same thought when setting this up.

I'd also like to point out that your default for "partition_inds = 1" is not the same as "partition_list = 1:length(tree.message)". These default values need not be the same in the future...

This is tricky. partition_inds = n::Int will be the vast majority of uses for this (and almost always n=1, but we do want to allow a vector/range/etc for advanced use-cases. This is unlike the existing uses with partition_list, like the LL, where almost all uses will want 1:num_partitions so all data is used for the likelihoods. For the likelihood calculations, it is ok if single Int args are not allowed, because a user needs to be doing something pretty advanced to want to depart from the default, and once you're not dealing with a single partition it makes semantic sense that you should reduce over a range for eg. the LL.

but I do think we should replace all instances of "partition_list" with "partition_inds".

Ja, it is just the right name for it. Very breaking, but few use cases would have departed from the default anyway.

[nossleinad]

For the likelihood calculations, it is ok if single Int args are not allowed

You can let partition_list = n::Int currently though since

julia> for i in 1
       println(i)
       end
1

[murrellb]

Yes when accumulating LLs, but there are many things like this throughout the code, where an Int index will return a partition instead of a message: