tinyplot icon indicating copy to clipboard operation
tinyplot copied to clipboard

Pass `ymin` and `ymax` through `formula`

Open grantmcdermott opened this issue 1 year ago • 4 comments

Creating a new issue from this comment by https://github.com/grantmcdermott/tinyplot/issues/224 by @zeileis

Would we want to be able to specify ymin and ymax through the formula?

grantmcdermott avatar Dec 13 '24 00:12 grantmcdermott

Replies from the same thread:

@grantmcdermott

Related question: Would we want to be able to specify ymin and ymax through the formula?

Yes!

Honestly, this is something that I'd love to have a "good" syntax for. I'm all ears if you have ideas. We should probably open a separate issue to discuss.

P.S. The way that base plot handles this AFAICT is to allow ymin/ymax passing through NSE. I can't think of an example off the top of my head, though...

@vincentarelbundock

Not a strong preference, but I feel that we already have arguments called ymin and ymax, and it's generally good to have only one way of doing things, and to avoid overloading the formula. by is a very common use-case, and I think it might be confusing if the formula is used for more than that.

But again, this is a relatively weak preference.

@zeileis

Well, we can either use standard non-standard evaluation when building the model.frame(). This would be like weights = ... or offset = ... in regression functions like lm() and glm(). So we could include ymin and ymax there. BTW: weights might also be handy, especially for categorical data but also for pre-binned data.

Alternatively, we could have formulas like cbind(ymin, y, ymax) ~ x | by. But then we would need to decide whether to turn multivariate responses into matrices or data frames etc.

grantmcdermott avatar Dec 13 '24 00:12 grantmcdermott

Do we have some consensus on this, yet?

My personal preference would be to identify arguments that we want to handle along with the model frame (but not inside the main formula), e.g., ymin, ymax, weights, and probably also facet (unless its "by" or a formula). Thus, I would avoid the cbind()-based ideas.

zeileis avatar May 18 '25 11:05 zeileis

@zeileis I'm not sure I understand your question or proposal.

Is this a change in the user interface? To what?

Or is this internals only?

vincentarelbundock avatar May 18 '25 11:05 vincentarelbundock

@vincentarelbundock I believe @zeileis means allowing NSE variables to be added to the formula model.frame the same way that base R does for certain functions, e.g. in lm(y ~ x, data, weights = w).

In our case, it would look like, say:

plt(y ~ x, data, ymin = lwr, ymax = upr)

etc. instead of

plt(cbind(y, lwr, upr) ~ x, data)

At any rate, I'm in favor of this too. The one complication (well, apart from implementing it) is that it may block some of the design ideas I had for passing nested colors in #343, but I need to refactor that code anyway.

@zeileis As our resident formula expert would you be able to take the lead on this? I guess we can re-use the same NSE logic that base R does in equivalent cases.

grantmcdermott avatar May 18 '25 16:05 grantmcdermott

Now in PR #403 with some explanations and examples.

zeileis avatar May 19 '25 00:05 zeileis