Plotly 直方图值的精度 %{x}

precision in Plotly histogram value %{x}

我正在使用 Plotly 来显示带有悬停模板的直方图,该模板显示组中的值。我需要将精度显示为 3 位数,即使数据很大,但是 Plotly 似乎将之前的值四舍五入,因此在下面的示例中,hovertempalte 从“28200.000 - 28500.000”跳转到“28600.00 - 28800.00”并且值 28589.02 被吸收到第二个柱线,而它低于范围的最小值。

是否有任何选项可以更改 %{x} 值的精度?我尝试使用 hoverformat: .3f 但它只在末尾添加 0,因此无法修复。

您可以在此处找到示例:https://stackblitz.com/edit/typescript-plotly-hfluqw?file=index.ts

const appDiv: HTMLElement = document.getElementById('app');
appDiv.innerHTML = `<div style="width: 100%; height: 100%" id="chart"></div>`;
import { newPlot } from 'plotly.js-dist';

const data = [
  {
    type: 'histogram',
    marker: { color: 'red' },
    mode: 'lines+markers',
    x: [25000, 28333.952, 28334.08, 28589.02, 28945.89],
    xbins: {
      start: 25000,
      end: 29340.479,
      size: 394.589,
    },
    hovertemplate: 'value: %{x}',
  },
];
const layout = {
  bargap: 0.1,
  hovermode: 'closest',
  xaxis: {
    hoverformat: ',.3f',
  },
};

newPlot('chart', data, layout);

编辑:修复范围间隙内的点

我最终通过从 xbin 中删除开始和结束值来解决我的问题的最大部分,将其保留为 Plotly 逻辑中的默认值。 显示的值仍然是四舍五入的,所以有一个跳跃,但范围总是覆盖所有点,所以在上面的例子中,范围被固定为“28.1k - 28.4k”和“28.5k - 28.7k”。我认为开始和结束正在改变这一点并打破了一些 Plotly 舍入逻辑。

不幸的是,目前这似乎是预期的行为,这就是 Plotly 内部 bin 范围“收缩”的工作方式。

有一个 open Github issue asking a similar, more simple question: How come a bin size of 50 displays ranges of 0-40, 50-90, etc, as shown in this live demo?

开发者说明:

This is all in service of greater clarity at the bin edges. To be precise, what's happening here is two things:

  • We detected that the data values are all integers, so we shifted the bin edges down 0.5 to ensure that NO values are exactly at a bin edge. You can see this if you zoom in, the bins actually go -0.5 -> 49.5, 49.5 -> 99.5, 99.5 -> 149.5 etc
  • But listing exactly those values in the hover label would be confusing: what are half-integer values doing in a label for integer data? So we look at the data again and ask: what's the closest any value gets to the left or right edge of a bin? In this case it's 0.5 from the left edge and 9.5 from the right, and based on the bin width of 50 we can always represent these values with a zero at the end, so that's what we do - 0-40, 50-90, 100-140 etc. If you add a value that's just a little closer to the right edge of a bin - say change one of the 140s to 141 - you'll see the labels change to 0-49, 50-99, 100-149 etc, since we can no longer round to a bigger digit.

What we really DON'T want to do is have labels 50-100 and 100-150, because then it's ambiguous in which bin we put a value of exactly 100. But you could perhaps argue that the bin shift should match the range shrinkage - ie because we shifted the bins exactly 0.5 here we should also shrink the ranges we report by exactly 0.5 on each side, to 50-99, or if we want to keep 50-90 we should shift the bins by 5.

此解释也适用于您的情况:如果您尝试添加值 28551,它恰好位于第 9 个 bin 的第 8 个 bin\left 边缘的右边缘(因为:25000 + (394.589 * 9) = 28551.301),您会注意到悬停的 bin 边缘变得非常精确 - as you can see here.

所以看起来没什么可做的,至少现在是这样。