Skip to content
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

super hacky fix to issue #1310 #1659

Closed
wants to merge 2 commits into from

Conversation

tacaswell
Copy link
Member

The last entry in locs is laundered through val = float(str(val))

issue #1310

@WeatherGod
Copy link
Member

Are we even able to assume that MultipleLocator deals only with numerical values?

@tacaswell
Copy link
Member Author

I think that if you tried to put any other type in it would be cause issues going through the Base class.

@mdboom
Copy link
Member

mdboom commented Jan 16, 2013

This seems worthy of backporting to 1.2.x.

The last entry in locs is laundered through val = float(str(val))
@tacaswell
Copy link
Member Author

re-based to v1.2.x

@dhyams
Copy link
Contributor

dhyams commented Jan 18, 2013

I really wouldn't do this. I'll admit that I'm not sure what the right fix is yet, but this particular fix gives very little control over when the last tick appears and when it doesn't. What if I'm plotting things at very small scale, such that the 1e-15 matters?

I'll go digging, but there has to be some code somewhere that is doing the chopping of the locator "locs" to the current view limits. It's that code that needs to have a proper tolerance implemented, if it doesn't already.

@WeatherGod
Copy link
Member

@dhyams That is an extremely good point and should be the reason not to accept this PR.

@dhyams
Copy link
Contributor

dhyams commented Jan 20, 2013

I have submitted another pull request to address this problem, as an alternative to this one.

#1686

@dmcdougall dmcdougall mentioned this pull request Jan 27, 2013
@dmcdougall
Copy link
Member

I feel that #1686 poses a slightly more appropriate solution so I'm going to close this PR in favour of #1686.

If @tacaswell (or anybody else) feels that this PR is indeed preferred over #1686, please feel free to re-open this.

@dmcdougall dmcdougall closed this Jan 27, 2013
@tacaswell
Copy link
Member Author

I hope my feelings about this patch is clear from the name of the PR.

On Sun, Jan 27, 2013 at 1:00 PM, Damon McDougall
notifications@github.comwrote:

I feel that #1686 https://github.com/matplotlib/matplotlib/issues/1686poses a slightly more appropriate solution so I'm going to close this PR in
favour of #1686 #1686.

If @tacaswell https://github.com/tacaswell (or anybody else) feels that
this PR is indeed preferred over #1686#1686,
please feel free to re-open this.


Reply to this email directly or view it on GitHubhttps://github.com//pull/1659#issuecomment-12759174.

Thomas Caswell
tcaswell@gmail.com

@tacaswell tacaswell deleted the issue_1310_fix branch August 14, 2014 00:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants