Open benthestatistician opened 3 years ago
Would you see any reason to hesitate with either of the options proposed in this issue, (1) or (2), if they didn't break the current tests? @markmfredrickson @josherrickson
Anything that simplifies match_on.function
gets my support. What about also supporting a version that just takes in a pair of points and returns a distance between them; handling the index
internally? I feel like that would live up to the promise of "just define any distance metric" better than having users worry about vectorization of functions.
No argument about removing z
. I'm sure I had a reason for that at some point, but looking at the test file doesn't include any examples.
match_on.function()
expects its first argument to be a function with 3 arguments,index
,data
andz
. But in many cases, including each of my uses of it as well as the example discussed inline in the documentation, only the first two are used. This adds a disorienting element to our explanation:z=
argument.match_on()
that either do or do not take az=
argument, provided that we insist they takeindex
anddata
arguments. In particular, before this point inmakedist.R
we check whether
any(names(formals(distancefn))=="z")
and if not then instead doEither way this is an API change appropriate to a major version bump (#134) .