René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"A reasonable default width for bar() with units?","articleBody":"In #12903 we merged a PR fixing the handling of the default `width` (0.8) when `bar` (`barh`, `broken_barh`) is called with unitized data (I was among the PR approvers; see also #13187 as followup).  Briefly, the idea is to support both unitless and unitized widths, so that one can do\r\n```\r\nbar([dates])  # default width: 0.8\r\nbar([dates], width=[timedeltas])  # or single timedelta\r\nbar([categoricals])  # default width: 0.8\r\nbar([categoricals], width=[unitless])  # or single scalar\r\n```\r\nThe main trickiness is that the default width is unitless (0.8), but one can also pass a unitful width, so it's not clear how to add it to the unitized `x`; moreover, note that the unit of `x` can either correctly handle addition (time + timedelta), or not (categoricals, which need to go through the converter first).  So the end design is something like\r\n```\r\ntry:\r\n    dx = deunitize(orig_x + orig_dx) - deunitize(orig_x)\r\nexcept ...:\r\n    dx = deunitize(orig_dx)\r\n```\r\nwhere orig_x and orig_dx are the user inputs, either unitized or deunitized.\r\n\r\nHowever, I now feel like this is not really looking at the problem under the right angle: if the user input is unitized, what's the chance that 0.8 \"deunitized-units\" is a reasonable default width?  It is rather low, I would guess.  Instead, it would seem that the intent of the default would/should be \"0.8 times the spacing between the bars\" (in the common case of evenly spaced bars).\r\n\r\nHence, a solution may perhaps be to change the interpretation of a unitless `width` in the case of unitized data, to have it mean (e.g.) a fraction of the (mean) spacing between the bars (i.e. `(max(x) - min(x)) / (n - 1)`).  Note that because `bar` did not support unitized data up to now, there are no backcompat concerns.\r\n\r\nMostly @jklymak I guess.  Allowing myself to mark this as release critical mostly so that we don't have to go through a painful deprecation period if we agree on this, but feel free to untag.","author":{"url":"https://github.com/anntzer","@type":"Person","name":"anntzer"},"datePublished":"2019-01-20T06:37:27.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":41},"url":"https://github.com/13236/matplotlib/issues/13236"}