You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The docstring for various sizes arguments states that size is given as symbol area in square points. Checking with matplotlib.Collections code, this argument doesn't actually calculate the symbol area, but instead is a squared scale factor. This might lead to a wrong interpretation especially if irregularly-shaped symbols are used, but it also not correct for circles. On a more general basis, is it not easier to use linear scale factor as an argument, instead of its square? I just don't see applications where the latter is more useful than the former.
I agree. It arose historically from matching Matlab's behavior in scatter(), so the only way to get away from it is to provide an alternative kwarg and encourage its use. I would guess that the original Matlab motivation for using area was the idea that visual size of a blob scales with area, not diameter. For example, if symbol size represents population of a city, it is reasonable to have area of the symbol be proportional to population. From the standpoint of a plotting library, however, I think it is much better to let the user do the squaring when desired, and to use linear dimensions in the plotting command.
If we decide to move forward on this, the solution is likely to be an alternative kwarg that specifies size based on a simple linear metric. There is also the possibility of allowing a norm function, but I think this would be overkill--more complexity than real-world applications can justify.
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
Activity
efiring commentedon Aug 17, 2012
I agree. It arose historically from matching Matlab's behavior in scatter(), so the only way to get away from it is to provide an alternative kwarg and encourage its use. I would guess that the original Matlab motivation for using area was the idea that visual size of a blob scales with area, not diameter. For example, if symbol size represents population of a city, it is reasonable to have area of the symbol be proportional to population. From the standpoint of a plotting library, however, I think it is much better to let the user do the squaring when desired, and to use linear dimensions in the plotting command.
efiring commentedon Mar 21, 2016
If we decide to move forward on this, the solution is likely to be an alternative kwarg that specifies size based on a simple linear metric. There is also the possibility of allowing a norm function, but I think this would be overkill--more complexity than real-world applications can justify.
github-actions commentedon Oct 9, 2023
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
akhmerov commentedon Oct 11, 2023
I think this is still a valid issue, and the arguments above apply to the same extent as they did before.
github-actions commentedon Oct 14, 2024
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
jklymak commentedon Oct 14, 2024
Put the keep label on, it necessarily because I think we should do anything about this, but it is definitely still the behaviour