It's a bit conspicuous that {tdarec} provides a step function for each vectorization, e.g. step_vpd_betti_curve(), while {inphr} provides the representation parameter, taking values like "betti", for a single function. Maybe the different packages call for different behaviors, but i'd like to discuss this and make a deliberate decision.
First, should we make the names agree? {tdarec} uses the same names as {TDAvec}, with the compute prefix dropped and the rest converted from CamelCase to snake_case. {infer} uses shortened names, which are nevertheless unambiguous—though it's possible that some, e.g. "betti", might become ambiguous later.
Second, what are the trade-offs between having separate functions versus a parameter? Here are my thoughts:
- Having separate functions forces the user to choose one; a parameter allows for a default.
- Function names can be tab-completed, while parameter values can't.
- Separate functions flood the namespace and documentation; a parameter simplifies both.
- Separate functions can have their own unique arguments, which can be tab-prompted; a single function with a
representation parameter would either have to process ... or accept a list argument, e.g. params = list(power = 2), either way requiring the user to remember or recover their names. (Currently {inphr} does neither; representation-specific arguments take their default values.)
Maybe the trade-offs work one way for {tdarec} and another way for {inphr}. @astamm i'm interested in your thoughts.
It's a bit conspicuous that {tdarec} provides a step function for each vectorization, e.g.
step_vpd_betti_curve(), while {inphr} provides therepresentationparameter, taking values like"betti", for a single function. Maybe the different packages call for different behaviors, but i'd like to discuss this and make a deliberate decision.First, should we make the names agree? {tdarec} uses the same names as {TDAvec}, with the
computeprefix dropped and the rest converted from CamelCase to snake_case. {infer} uses shortened names, which are nevertheless unambiguous—though it's possible that some, e.g."betti", might become ambiguous later.Second, what are the trade-offs between having separate functions versus a parameter? Here are my thoughts:
representationparameter would either have to process...or accept a list argument, e.g.params = list(power = 2), either way requiring the user to remember or recover their names. (Currently {inphr} does neither; representation-specific arguments take their default values.)Maybe the trade-offs work one way for {tdarec} and another way for {inphr}. @astamm i'm interested in your thoughts.