issue_comments: 269553467
This data as json
| html_url | issue_url | id | node_id | user | created_at | updated_at | author_association | body | reactions | performed_via_github_app | issue |
|---|---|---|---|---|---|---|---|---|---|---|---|
| https://github.com/pydata/xarray/pull/1171#issuecomment-269553467 | https://api.github.com/repos/pydata/xarray/issues/1171 | 269553467 | MDEyOklzc3VlQ29tbWVudDI2OTU1MzQ2Nw== | 85125 | 2016-12-28T22:45:26Z | 2016-12-28T22:45:26Z | NONE | It's not a bug in the code. The purpose of a Locator is to find "nice" values for ticks. It is used in two related ways: to determine the axis limits when the pre-2.0 default of "round numbers" (meaning "landing on ticks") is use, and to find the tick locations themselves. Supporting the former application requires generating ticks beyond the specified limits; then later in the plotting process, the excess ticks might be used, or they might be trimmed off, depending on how the axis limits are determined. In no case is it intended that ticks land on specified vmin and/or vmax values, though it can happen by chance if they are "nice" numbers. In the case of the MaxNLocator, the "N" refers to intervals, not ticks; that is, in "round-number" axis limit mode, or if vmin and vmax otherwise land on ticks, there can be N+1 ticks. (This is in the docstring; and the argument is called "nbins", not "nticks".) |
{
"total_count": 0,
"+1": 0,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
196278181 |