Github user felixcheung commented on the issue:
https://github.com/apache/spark/pull/16729
@actuaryzhang that's true, it's not ideal.
This is somewhat an unusual case for R for several reasons.
In my head the guiding principles are:
- we avoid depending on another package (eg. `statmod`)
- we avoid naming a method/class that masks another *popular* package
- we can't ask user to call into private API
- we could use another package, for convenience, if it's loaded, but
generally (*I'd agree*) we should avoid to minimize confusion or unpredictable
behavior.
But since in this method we have this odd design where we take a R function
(R `glm` family), and don't really use it, I thought it makes sense to allow
the user to pass it in, that's why I suggested earlier as
> add var.power link.power as parameter? I realize that is closer to what
you have originally, but in addition to 2 new parameters we could also check if
tolower(family$family) == "tweedie" and if so, get family$var.power instead, so
in this case it would work when statmod is there, and it would still work when
it is not. (but in addition, for consistency we would need to make passing
"tweedie" as a string also work - but that wouldn't be much different from
tweedie is a function)
In the case `statmod` is loaded and the user is passing in `tweedie` in the
family param, do we not need to explicitly check for it
[here](https://github.com/apache/spark/pull/16729/files#diff-2e1e5d49cfda9702645a955f584572eeL96),
since it is a valid function? IF we are going down this path, perhaps we
should have whitelist instead of a blacklist?
Also the other concern is we do have another [signature
`glm`](https://github.com/apache/spark/blob/master/R/pkg/R/mllib_regression.R#L147)
where we "overload" the existing `stats::glm` one. In this case we can't add
additional param like var.power or link.power, I think?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
