Skip to content

#2150 Updating patch limits if either width or height is non zero: Issue 2150 #2942

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from

Conversation

sfroid
Copy link
Contributor

@sfroid sfroid commented Mar 30, 2014

Previously, we would not update the patch limits, if either width or height of the patch were 0.

Now, if either width is non zero (vertical bar graph with zero entries) or height is non zero (horizontal bar graphs), the patch limits will be updated. If both width and height are zero, the patch will be ignored.

@sfroid
Copy link
Contributor Author

sfroid commented Mar 30, 2014

@tacaswell
Thomas, I have created the pull request to get your feedback. Do you think this is the correct and complete solution for #2150 ?
I have tested horizontal and vertical bar graphs with leading and trailing zeros and it gives the correct and expected output.

If so, I will add image tests and polish it for merging.

@tacaswell
Copy link
Member

It seems reasonable to me and all of the tests pass, however I am worried about un-intended consequences. @efiring or @mdboom should sign off on this on.

If there is not some compelling reason that this logic must be an or, this is much better than the proposed solutions of passing extra hints to the auto-limit code.

One of the fun things about a large code base is you tend to assume things are done some way 'for a reason'.

I am a bit concerned by the 'merge from master' in the history. Our practice is to keep re-basing branches if the conflict with master.

@efiring
Copy link
Member

efiring commented Mar 31, 2014

The comment in update_patch_limits says the rationale for "or" is that otherwise log scaling has problems. I don't know offhand whether this is still the case, and if so, whether there might be a better solution to that problem. Apart from that, the "and" proposed here seems reasonable.

@tacaswell
Copy link
Member

@sfroid This needs to be rebased (conflicts in CHANGELOG).

Did you get a chance to investigate how this interacts with log?

@tacaswell tacaswell added this to the v1.4.0 milestone Apr 20, 2014
@tacaswell
Copy link
Member

It seems to work fine with log-scaling.

Closing because I merged the non-merge commits on a local machine and pushed to master.

@tacaswell tacaswell closed this May 18, 2014
@pelson
Copy link
Member

pelson commented May 20, 2014

@tacaswell - I know it adds a small overhead, but would you mind linking to the change if you end up doing it by hand? It just makes it easier to find what has gone on where. Thanks 😄

@tacaswell
Copy link
Member

Sorry about that, I will take care of this next time I am at a real computer.

@tacaswell
Copy link
Member

Merged in 899f11d

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants