Let me understand the bug: When using `seaborn` with large numbers, the legend values are formatted without their multiplicative offset value. For example, if `body_mass_mg` is in the order of 1E6, the legend might show values like "1000000", "2000000" etc. as just "1", "2" etc., missing the offset/scale factor. The user points to a specific location in the code: https://github.com/mwaskom/seaborn/blob/ba786bc14eb255f6b4fb7619c8210c5a8016a26f/seaborn/_core/scales.py#L377-L382 Let me look at the current code.

Now let me look at the specific lines referenced in the issue (around line 377-382 in the original GitHub link). The current file has been modified, but the relevant code is in the `_setup` method of `ContinuousBase` class. Let me look at the legend creation part: ```python if prop.legend: axis.set_view_interval(vmin, vmax) locs = axis.major.locator() locs = locs[(vmin <= locs) & (locs <= vmax)] labels = axis.major.formatter.format_ticks(locs) new._legend = list(locs), list(labels) ``` The issue is that when `ScalarFormatter` is used, it may produce an offset (like "1e6") that gets displayed on the axis, but the individual tick labels don't include the offset. The offset is a separate piece of text. When `format_ticks` is called on a `ScalarFormatter`, the individual labels might be like "1.0", "2.0", etc., and the offset "1e6" is stored separately. Let me check how `ScalarFormatter.format_ticks` works and what `offset` attribute is available. In matplotlib's `ScalarFormatter`, there's an `offset` attribute that holds the multiplicative factor (e.g., 1e6) when the formatter uses an offset. The `get_offset()` method returns the offset text. So the fix should be: when retrieving labels from the formatter, check if the formatter has an offset, and if so, incorporate it into the legend labels or title. Let me look at how this is used in the legend rendering to understand how `_legend` is consumed.

Let me look at how `_legend` from scales is used in the plotting code.

The key line is `seaborn/_core/plot.py:1562`. Let me look at how `_legend` is used there.

Let me look at plot.py around line 1562.

Now let me look at how `labels` are used when rendering the legend.

Now I understand the flow: 1. In `ContinuousBase._setup` (in scales.py), legend values and labels are created: ```python locs = axis.major.locator() locs = locs[(vmin <= locs) & (locs <= vmax)] labels = axis.major.formatter.format_ticks(locs) new._legend = list(locs), list(labels) ``` 2. The `labels` from `format_ticks` for `ScalarFormatter` will be formatted without the offset. The offset is stored separately in the formatter's `offset` attribute (or retrieved via `get_offset()`). 3. These labels are then used directly in the legend. The bug is that when `ScalarFormatter` uses an offset (like `1e6`), the individual tick labels are like `"1.0"`, `"2.0"`, etc., and the legend shows these values without the offset, making them wrong. The fix should check if the formatter has an offset, and if so, incorporate it into the labels. Let me look at how `ScalarFormatter` handles offsets. In matplotlib, `ScalarFormatter` has: - `get_offset()` method that returns the offset text (e.g., `'1e6'`) - `offset` attribute But actually, looking at this more carefully, when `format_ticks` is called, the ScalarFormatter might or might not include the offset in the returned labels. Let me check. Actually, `ScalarFormatter.format_ticks(values)` returns a list of strings. The offset is NOT included in individual tick labels - it's a separate piece of text displayed near the axis. So when we use `format_ticks` to get legend labels, we lose the offset information. The fix should be: after getting labels from `format_ticks`, check if the formatter has an offset string, and if so, modify the legend to indicate the offset. There are a few approaches: 1. Modify the labels to include the offset (e.g., "1.0" + " × 1e6") 2. Add the offset to the legend title 3. Use the `get_offset()` method of the formatter Let me look at what `ScalarFormatter` provides.

So the offset is computed by `set_locs` and the `get_offset()` returns `'1e6'`. The labels are `['1', '2', '3']` without the offset. Now, the legend shows `1, 2, 3` but should show something like `1e6, 2e6, 3e6` or indicate the scale. Let me check how the formatter is used in the `_setup` method. The formatter is stored in `axis.major.formatter`. When the axis is a `PseudoAxis`, `set_default_locators_and_formatters` calls `axis.set_major_formatter(major_formatter)` which sets `self.major.formatter = formatter` and calls `formatter.set_axis(self)`. But when `format_ticks` is called, the formatter may need to have its `set_locs` called first to compute the offset. Let me check if `format_ticks` calls `set_locs` internally. Looking at matplotlib source, `ScalarFormatter.format_ticks(values)` does NOT call `set_locs`. `set_locs` needs to be called separately, and it's typically called by the axis machinery during drawing. But here we're calling `format_ticks` manually on the formatter. So the issue is twofold: 1. `set_locs` might not have been called on the formatter, so the offset might not be computed. 2. Even if the offset is computed, `format_ticks` doesn't include it in the returned labels. Let me check what the current code does:

So even without explicitly calling `set_locs`, the ScalarFormatter still computes the offset when `format_ticks` is called. But the offset is not included in the labels. The `get_offset()` method returns `'1e6'`. Now let me look at how the legend is built and think about the best fix. The fix should be in `ContinuousBase._setup` where `_legend` is created. Currently: ```python if prop.legend: axis.set_view_interval(vmin, vmax) locs = axis.major.locator() locs = locs[(vmin <= locs) & (locs <= vmax)] labels = axis.major.formatter.format_ticks(locs) new._legend = list(locs), list(labels) ``` We need to check if the formatter has an offset, and if so, adjust the labels accordingly. There are several ways to fix this: 1. Append the offset to each label 2. Include the offset in the legend title 3. Use `set_locs` explicitly and then format ticks with offset awareness Let me think about what makes sense. Looking at how matplotlib itself handles this in colorbars: colorbars also use a formatter and they show the offset text separately (like "1e6" above the colorbar). For a legend, I think the most natural fix would be to include the offset in the labels themselves. For example, if the labels are `['1', '2', '3']` and the offset is `1e6`, the legend should show `['1e6', '2e6', '3e6']`. But wait, that might not be correct either. The offset is a multiplicative factor. The actual values are 1×1e6 = 1,000,000; 2×1e6 = 2,000,000; 3×1e6 = 3,000,000. So showing "1e6" as a label for 1,000,000 makes sense. But the formatter already formats values as "1", "2", "3" with the offset "1e6" separate. Actually, let me check how `LogFormatterSciNotation` handles this:

Right, the formatter needs an axis to compute the offset. In seaborn's code, `axis.major.formatter` has `set_axis` called on it (via `axis.set_major_formatter`), so it should have an axis reference. Let me verify the flow in the seaborn code. Looking at `ContinuousBase._setup`: 1. `mpl_scale.set_default_locators_and_formatters(axis)` is called 2. Inside that, `axis.set_major_formatter(major_formatter)` is called 3. `PseudoAxis.set_major_formatter` sets `self.major.formatter = formatter` and calls `formatter.set_axis(self)` So the formatter should have `axis` set. So `format_ticks` should work. Now, the fix. Let me look at the specific lines again: ```python # Lines 377-382 (approximately) if prop.legend: axis.set_view_interval(vmin, vmax) locs = axis.major.locator() locs = locs[(vmin <= locs) & (locs <= vmax)] labels = axis.major.formatter.format_ticks(locs) new._legend = list(locs), list(labels) ``` The fix should check the formatter for an offset and incorporate it. Let me think about the best approach: 1. Check if the formatter has `get_offset()` method and if the offset is non-empty. 2. If so, we could either: a. Prepend/append the offset to each label b. Use the offset in the legend title Actually, looking at the matplotlib colorbar code for reference: colorbars have their own way of displaying the offset. But for a legend, I think the most user-friendly fix is to not use the ScalarFormatter's offset feature at all for legend labels. Instead, we should format the tick values directly using a formatter that doesn't use an offset. Wait, but the formatter is user-configurable. If the user specifies a custom formatter, we should use it as-is and just handle the offset correctly. Let me think again. The real issue is: - `ScalarFormatter` with large numbers produces labels like `['1', '2', '3']` and an offset of `1e6`. - The legend shows `1, 2, 3` which is misleading because the actual values are 1e6, 2e6, 3e6. The simplest fix: after getting labels from `format_ticks`, check if the formatter has a `get_offset()` method and if the offset string is non-empty. If so, include it in the labels. But how should we include it? We could: 1. Add "×1e6" to each label: `['1×1e6', '2×1e6', '3×1e6']` - this is verbose 2. Add the offset to the title: title becomes "body_mass_mg (1e6)" - but this changes the title 3. Format the actual values (locs) with the offset applied: `['1000000', '2000000', '3000000']` - this loses the formatting 4. Actually use the locs values to compute proper labels: since locs = [1000000, 2000000, 3000000], we should format them to show as "1e6", "2e6", "3e6" Wait, let me reconsider. The `locs` are the actual tick positions, e.g., `[1000000, 2000000, 3000000]`. The formatter formats these as `['1', '2', '3']` with offset `1e6`. But the legend should show the actual values. Actually, the real question is: what does the offset represent? Let me look more carefully at the ScalarFormatter behavior:

So when the offset is used, the labels are just "1", "2", "3" and the offset "1e6" is shown separately. The legend currently shows just "1", "2", "3" which is wrong. The fix should ensure that when the formatter has an offset, the legend labels incorporate it. I think the best approach is to multiply the offset string into the labels. For example: - If offset is "1e6", labels become "1e6", "2e6", "3e6" But we need to be careful: the offset is a string like "1e6". We can't just append it to the labels because: - "1" + "1e6" = "11e6" which is wrong - We need "1 × 1e6" or just use the value * offset Actually, looking at this more carefully, the ideal fix would be to NOT use `format_ticks` and instead format the values directly, or to incorporate the offset. But actually, let me look at what happens for `LogFormatterSciNotation` - it formats each value individually with scientific notation. `EngFormatter` also handles each value. The issue is specifically with `ScalarFormatter` which uses an offset. Let me look at how `ScalarFormatter` computes its offset and whether we can just get the proper labels another way. One approach: if the formatter is a `ScalarFormatter` (or has a `get_offset()` method that returns a non-empty string), we could: 1. Call `format_ticks` to get the base labels 2. For each label and its corresponding loc value, if the offset is non-empty, we could format it as `f"{label}{offset}"` but this would be like "1" + "1e6" = "11e6" which is wrong. Actually wait, let me check: does "1" × "1e6" mean the value is 1,000,000? If so, the label should be "1e6" for the tick at 1,000,000. But the legend labels should represent the actual values. If the tick is at 1,000,000, the legend should show "1,000,000" or "1e6" or "1 × 10⁶". Let me think about what the right fix is. The issue reporter suggested: > The offset value can be safely retrieved from all formatters and based on that it can be used to create the legend title and/or labels. I think the cleanest approach is: - When the formatter has a non-empty offset, modify the legend labels to include the offset in a readable way. Let me look at what `ScalarFormatter.get_offset()` returns exactly: It returns an empty string if no offset is used, or a string like "1e6" if an offset is used. For the labels, we could: 1. Prepend/append: e.g., if labels are ["1", "2", "3"] and offset is "1e6", make labels ["1e6", "2e6", "3e6"]. But this is mathematically wrong: 2e6 = 2,000,000 which is correct, but label "2" means the tick is at 2*offset = 2,000,000. So "2" + offset_text would be "21e6" which is wrong (it should be "2e6" or "2 × 1e6"). So we can't just concatenate. We need to interpret the offset differently. Actually, the offset returned by `ScalarFormatter.get_offset()` is a string like "1e6". This is the multiplicative factor. The tick at position 1,000,000 is displayed as "1" on the axis, and the offset "1e6" is shown separately. For the legend, we want to show the actual value. We could: 1. Show the loc value directly (1,000,000) formatted in some reasonable way 2. Show the label and offset combined properly Let me consider what matplotlib's colorbar does. Looking at `ColorbarBase`, it has its own formatter for the colorbar ticks. The colorbar uses `format_ticks` which includes the offset handling. I think the most robust fix is: after getting the labels from `format_ticks`, check if the formatter has an offset (via `get_offset()`). If the offset string is non-empty, we should modify the labels to be `f"{label} \u00d7 {offset}"` or similar, or better yet, compute proper labels from the loc values. Actually, the simplest and most correct fix might be to not just use `format_ticks` for the labels but to properly handle the offset. Let me look at how `format_ticks` could be made to include the offset. Looking at the ScalarFormatter source in matplotlib, `format_ticks` calls `__call__` for each value, which formats the value considering the offset. The off ... [truncated 658 characters]

Let me look at `locator_to_legend_entries` in utils.py, which is used by the non-objects interface:

So in the relational plot code, `locator_to_legend_entries` also uses `ScalarFormatter` and has the same bug! The comment even says "TODO: The following two lines should be replaced once pinned matplotlib>=3.1.0 with: formatted_levels = formatter.format_ticks(raw_levels)". But even `format_ticks` would have the same offset issue. But wait, let me check if the relational plot also has this bug. The issue reporter says "The issue also reproduces if you create the mentioned plot using `scatterplot`." So both places need to be fixed: 1. `seaborn/_core/scales.py` in `ContinuousBase._setup` 2. `seaborn/utils.py` in `locator_to_legend_entries` Let me look at the actual fix. The offset can be obtained via `formatter.get_offset()`. If it's non-empty, we need to incorporate it into the labels. For `ContinuousBase._setup`, the current code is: ```python labels = axis.major.formatter.format_ticks(locs) ``` We can add after that something like: ```python offset = axis.major.formatter.get_offset() if offset: labels = [f"{l}{offset}" for l in labels] ``` Wait, but this concatenation could be problematic. Let me check what `get_offset()` returns: - For ScalarFormatter, it returns a string like "1e6" or "×1e6" or something. Let me check more carefully:

So `get_offset()` returns `'1e6'`. The labels are `['1', '2', '3']`. The `EngFormatter` handles it properly. The issue is specifically with `ScalarFormatter` (and potentially other formatters that use an offset). Now, how to fix? If we just concatenate label + offset, we get "1" + "1e6" = "11e6", which is wrong. We need to show it as "1e6", "2e6", "3e6". Wait, but "1" + "1e6" = "11e6" ≠ 1,000,000. The actual value is 1 × 10⁶ = 1,000,000. So the legend label should be "1e6" (which equals 1,000,000). But the label is "1" and the offset is "1e6". The correct representation of the value is: - "1 × 10⁶" or "1e6" or just the original loc value formatted differently. If we show "1e6" for each tick: "1e6", "2e6", "3e6", these correspond to 1,000,000, 2,000,000, 3,000,000 which is correct. But we can't just do `f"{label}{offset}"` because "1" + "1e6" = "11e6" (string concatenation). We need "1e6" not "11e6". Wait, let me re-read: the offset is "1e6". So the label should show the value as "{label}e6" or similar. But the offset string is "1e6", not "e6". The "1" in "1e6" is the base. Hmm, this is tricky. The offset returned by `ScalarFormatter.get_offset()` is a string representation of the multiplicative factor. For a factor of 1,000,000, it returns "1e6". For a factor of 1000, it would return "1e3". The tick labels on the axis are: - Display: "1", "2", "3" (the labels) - Plus an offset text: "1e6" (shown somewhere on the axis, like "× 1e6") So the actual values are: 1×1e6=1,000,000, 2×1e6=2,000,000, 3×1e6=3,000,000. For the legend, we could show: - Option 1: Show the raw loc values formatted without offset: "1000000", "2000000", "3000000" - Option 2: Show with offset as "1 × 1e6", "2 × 1e6", "3 × 1e6" - Option 3: Show as "1e6", "2e6", "3e6" Option 3 seems cleanest. But implementing it is tricky because we need to convert "1e6" into "e6" and then append it to each label. Actually wait, let me check what the offset string looks like for different values:

So the offset is only used when the numbers are large enough. The offset string is like "1e6". Now, for the legend, I think the right approach is: if the offset is non-empty, we should include it meaningfully. But how? Looking at what information we have: - `locs` = [1000000, 2000000, 3000000] - the actual tick positions - `labels` = ['1', '2', '3'] - the formatted tick labels without offset - `offset` = '1e6' - the multiplicative offset The correct legend labels could be: - Simply use the loc values formatted with `%g` or similar: "1e+06", "2e+06", "3e+06" - Or use the label with offset: "1 × 1e6", "2 × 1e6", "3 × 1e6" I think the best approach is to actually just use the loc values directly if there's an offset. Since the loc values are the actual numbers, we can format them as "1e6", "2e6", "3e6" using Python formatting. But actually, looking at this from a user perspective: the legend should show the actual values. If the formatter produces an offset, the legend should incorporate it. The simplest correct fix would be: If `formatter.get_offset()` is non-empty, we should not use the offset-truncated labels. Instead, we should format the loc values directly. The offset is used on the axis to save space, but in the legend, we have more room and should show the full values. Actually, let me look at how this is handled in `locator_to_legend_entries`: ```python formatter.set_locs(raw_levels) formatted_levels = [formatter(x) for x in raw_levels] ``` Here, `formatter(x)` calls `formatter.__call__(x)` which formats a single value. This will also use the offset if it's set. Let me check: