Current R interface isn't really an interface, but....

[mbrazeau]

The current R interface file isn't really an interface in the classic sense. It also makes quite a bit of the actual MorphyLib API opaque from the R side (which is why I've added the binding). So, it shouldn't really be a MorphyLib thing because it's providing higher-level facilities over what MorphyLib is intending to provide. But it does make a lot of sense to move it to the Inapp package, which can leverage MorphyLib later.

[ms609]

Thomas and I discussed this briefly and agreed that MorphyLib was not the right long-term home for the code – but that said, it doesn't quite seem to fit with the current purpose of the Inapp library, which is intended to provide a visual representation of the algorithm, but not to run tree searches.

I see three options:

1. Expand the remit of Inapp to include running (inefficiently) the algorithm on real trees
2. Create an entirely new repository providing this functionality
3. Updating my existing 'inapplicable' package, which already contains the infrastructure for efficient tree searching in R (well as applicable as you're going to get in R, anyway), to use the MorphyLib code.

I'm tending slightly towards the latter option, which will avoid some reinvention of wheels, though at the cost of there being some functions floating around that might be less applicable, and our quite different approaches to code/documentation formatting. But happy to pursue either of the alternatives.

[mbrazeau]

Agreed.

I'm happy to exploit the existing 'inapplicable' package for this. As it stands, I'm writing MorphyLib to more easily weight characters 'on the fly'. This will allow us to speed things up using the ratchet (already running in 'inapplicable'), but without the need for lower-level optimisations.

In fact, I don't see why 'inapplicable' can't expand to use Inapp and leverage Morphy.

Regarding code formatting: I have no strong preference about R formatting or commenting; my only view on code format and documentation is that it is readable and clear.

[TGuillerme]

Agreed as well. Let's separate the three things into distinct non-overlapping tools:

• MorphyLib as a standalone C library (we need to make sure we have strong documentation on that one to allow people to use it
• Inapp for visualising the algorithm (as appendix to the paper)
• inapplicable as a R package for doing tree searches with inapplicable data

However, I think there is no problems in using MorphyLib in both Inapp and inapplicable. Publication-wise, in my head, that sounds like two papers as well (or three?):

• The algorithm description paper (using Inapp) - that's nearly done
• The implementation paper (describing inapplicable and MorphyLib - or both in a separate paper)

What do you guys think?

[ms609]

The two-paper approach looks promising: as you say, we're pretty much there on describing the algorithm. By the time we demonstrate that our solution is philosophically and algorithmically robust, and discuss its implications for how matrices should be constructed (perhaps with guidelines to 'best practices') this should be a solid and substantial paper that we could conceivably be in a position to submit in the next month or so.

We will of course want to explore how our algorithm performs relative to existing methods; it makes sense to me do to this in an 'implementation paper' where we can use the implementations as a mechanism to explore how the algorithm performs, and how it affects the results of different datasets – this seems to be to be a bigger job with the scope to attract more demanding comments from reviewers, so I'd be all for leaving this component of the project to the implementation paper(s).

[mbrazeau]

Agreed all around. This is shaping up nicely.