Overall wrapper function

[wzbillings]

Now we have the wrapper function calculate_distance() which processes all the necessary arguments and invokes the correct method without users needing to call multiple different functions. Now we want to write another wrapper, say agdist() or whatever, that takes a vector of methods and returns all of the differences.

1. agdist() should have two methods: one for data frames and one for named vectors.
2. the method should validate the input, for dataframes we will need a way of specifying which columns to use e.g. by tidy evaluation (or requiring users to pass strings of the column names).
3. Then, the function should validate the methods argument and ensure its a valid character vector with only names of allowed methods.
4. Finally, we iterate through the methods argument and run compute_distance() with each method and the necessary other arguments. This function already validates the arguments for each method, so we don't need to do that again (e.g. compute_distance() will error if the user tries to get cartographic distances without passing in a map -- although we do need to implement a validation step that checks that the input data is compatible with the tree or map supplied see cartograpic and tree dist interfaces that accept sequence vector #3).
5. Once we have a list of distance matrices, we can then use the implemented tidy_dist_mat() to get clean dataframes and rbind them together to get an output matrix -- this will be the default output form although there should be an argument that allows users to get the list of distance matrices as well (sometimes this is useful, e.g. for making neighbor joining trees).
6. The data frame method will be easy to implement once the vector method is implemented. We would just take the two columns of strains to be compared, create a unique vector with all of the pairwise combos, and then run the vector method on that. Then the tidy distance matrix can be joined back to the original data frame. This is more memory intensive than doing it a different way but it's the easiest implemention that doesn't break any of the existing code.

[wzbillings]

I still think rewriting the distance methods to say distance_method(x, y = NULL) and do all pairwise distances if only x is specified, or do the elementwise distances if x and y are specified is a better idea, but AH already said he would just break all the code instead of doing that, so this solution is probably better with that in mind.

Pros of the joining method:

• Avoids duplicate distance calculations (the distance between strain A and strain B is only ever calculated once, instead of being calculated once for each row in which that combination appears) -- to ZB, this is the biggest reason to write the code the way he wrote it.
• Doesn't require rewriting any existance distance calculation code

COns of the joining method:

• Joining can be memory intensive on large datasets
• In many cases will do some calculations that are not required for the final output

Pros of finishing this issue at all:

• I can make sure it's done right
• I think it's a useful feature

Cons of finishing this issue at all:

• No matter which way I write it, AH will want it to be done a different way, so maybe it's best to just let someone else finish it