pull_requests: 99671769
This data as json
| id | node_id | number | state | locked | title | user | body | created_at | updated_at | closed_at | merged_at | merge_commit_sha | assignee | milestone | draft | head | base | author_association | auto_merge | repo | url | merged_by |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 99671769 | MDExOlB1bGxSZXF1ZXN0OTk2NzE3Njk= | 1191 | closed | 0 | Integer levels and vmin/vmax | 10050469 | Follow-up to https://github.com/pydata/xarray/pull/1171#issuecomment-269556898 From the new docstring: ``` levels : int or list-like object, optional Split the colormap (cmap) into discrete color intervals. If an integer is provided, "nice" levels are chosen based on the data range: this can imply that the final number of levels is not exactly the expected one. Setting ``vmin`` and/or ``vmax`` with ``levels=N`` is equivalent to setting ``levels=np.linspace(vmin, vmax, N)``. ``` The logic overhead is quite simple, which is an argument in favor of this simple solution. It is consistent with mpl, as long as neither vmin or vmax are set. It _might_ change the outcome of some existing plots, though. Should I mention this in the "Breaking changes" section too? | 2016-12-29T16:10:22Z | 2017-01-03T09:50:14Z | 2017-01-03T09:50:14Z | 2017-01-03T09:50:14Z | 71d6a0e8bc89d7bbb4f89590139946e9fdf4f57d | 0 | dace3eb864d191ce08c4ed5fdf713d892006ea70 | feed9223129fbb87cadf698275088687755cc12d | MEMBER | 13221727 | https://github.com/pydata/xarray/pull/1191 |
Links from other tables
- 0 rows from pull_requests_id in labels_pull_requests