Fixed the issue with wrong width in log scale for Bar(s) #3138
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes the issue #2907, but in a hacky way. The core issue is that currently, the bars' positions relative to each other are defined by a coordinate (say x) and their width. When applying a transform, what happens is that x is transformed (into
transformed_x
), and the new width is obtained withtransformed_width = transform(x+width/2)-transform(x-width/2)
. While this is actually correct, it falls apart when passing the coordinates to the matplotlib API, which asks for the bottom left of the rectangle. It is currently obtained by doingtransformed_x-transformed_width/2
, whereas it should really betransform(x-width/2)
, which is obviously not the same in the case of the log.In this PR, I solve the problem by storing the
transform(x-width/2)
value and retrieving it when needed, but this feels a bit weird to have it as an additional variable ; however we cannot ditch the normaltransformed_x
as it is needed for other things than the bars. There is probably some underlying flow change that would make this more straightforward but I expect this to be a big change.