Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slighltly improve coefnames with no intercept #301

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nalimilan
Copy link
Member

Adopt improvements from termnames (#299).

Adopt improvements from `termnames`.

See also [`termnames`](@ref).
"""
StatsAPI.coefnames(t::FormulaTerm) = (coefnames(t.lhs), coefnames(t.rhs))
StatsAPI.coefnames(::InterceptTerm{H}) where {H} = H ? "(Intercept)" : []
StatsAPI.coefnames(::InterceptTerm{H}) where {H} = H ? "(Intercept)" : String[]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tangential as this code is predates this PR but it's kind of odd IMO that coefnames can return a String rather than a container. The name is plural so it sounds like it should give you some collection of names, even if said collection has one element (or none).

Copy link
Member

@palday palday Sep 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not be opposed to always returning a container, even when it's just one element, but that would be technically breaking for coefnames albeit not termnames (because `termnames hasn't appeared in a release yet)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's true that the name is plural, but I'm not sure returning a single string is a problem in practice. Are people really likely to call this on objects which could either be single- or multiple-term? It's not super practical either to get a single-element vector when you know in advance there will be a single value, and in terms of our own implementation it's quite wasteful (though it probably doesn't matter much).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

teh return type is already all over the place since the FormulaTerm one returns a tuple, so I'm not too fussed about it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess that means the current docstring is wrong though...

Copy link
Contributor

@matthieugomez matthieugomez Dec 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @ararslan — always returning a container would be the best choice (and that’s what Julia does everywhere). And yes, it matters for developers that use coefnames inside their functions (as I needed to work around that in my packages)

Copy link
Member

@kleinschmidt kleinschmidt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with this overall, just a minor tweak to be super pedantic about the possible return values.

Comment on lines +572 to +573
Return value is either a `String`, an iterable of `String`s or the empty vector
if there is no associated column (e.g. `coefnames(InterceptTerm{false}())`).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Return value is either a `String`, an iterable of `String`s or the empty vector
if there is no associated column (e.g. `coefnames(InterceptTerm{false}())`).
Return value is either a `String`, an iterable of `String`s, the empty vector
if there is no associated column (e.g. `coefnames(InterceptTerm{false}())`), or
(in the case of a `FormulaTerm`) a two tuple of any of the above (corresponding
to `coefnames` applied to the left- and right-hand sides of the formula).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if I copied and adapted the docstring for termnames(t::FormulaTerm) instead? My goal was to make the two functions consistent, and the behavior for formulas seems different enough to deserve a separate docstring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants