| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Borrows heavily from @Tillsen's solution found on StackOverflow here: http://goo.gl/RPXMYB Used with his permission dicussesd on Github here: https://github.com/matplotlib/matplotlib/pull/3858`
This will allow the ticks of colors to be spaced as desired. Also simplified the math per the brilliant @joferkington http://stackoverflow.com/a/20146989/1552748
couldn't actually run the test suite b/c python iesn't installed as a framework.
Need to allow it in __call__ since colorbar can pass a value for clip.
To make it more similar to the other norms Also remove misleading comment about returning scalars
Since possibly some earlier versions of numpy returned a scalar, wrap the value in atleast_1d before indexing.
np.interp handles the case vmin == vcenter, we have to add a special case to make the last test case pass
|
Something that strikes me here, but I don't think for now, how the class inheritance goes
I.e. it should go from the most general at the end of the MRO to most specific at the top... instead we have the most specific, Normalise at the bottom... not something I specifically want to address now, both because I know I have a lot of more fundamental refactoring to do in this area, and I want to make sure I get that right before fiddling about here; and also because having slept on it, I would like to see the OrderedDict on the MRO, rather than existing as just an attribute, and that will have to wait until we drop python-2.6 |
Sorry, something went wrong.
|
@OceanWolf Normalize is not the most specific, it is the simplest and most common. It is no more ore less specific than any of its subclasses. Yes, one could split out a NormalizeBase and use that as the common ancestor for all. Is the gain in formal structure worth the additional LOC and the extra level of redirection for the Normalize case, which is probably something like 95% of real world usage? |
Sorry, something went wrong.
|
@efiring by most specific I mean that as far as I can tell Normalize does the same thing as DivergingNorm but with vcenter = np.mean([vmin, vmax]). DivergingNorm does the same thing as PiecewiseLinearNorm but with just one stop between vmin and vmax set specifically at the centre. I don't see what you mean by "additional LOC", as far as I see it we significantly reduce the LOC, i.e. the Normalise class becomes something like: class Normalize(DivergingNorm):
def __init__(self, vmin=None, vmax=None):
super(Normalize, self).__init__(vmin, None, vmax) |
Sorry, something went wrong.
|
Btw the is a lot of overlap between transforms and the norms, it would be nice - a properly quite difficult - to combine these. |
Sorry, something went wrong.
|
@Tillsten Yes, I have plans to do this with my MEP working on refactoring the axes #5029, I plan to merge the colourbar with the other axis code, essentially these Normalisations works as axis transformations, so it makes sense to me to simply the API here. As these extra norms have been pushed back to at least the 2.1 release next April, this gives me time to work on this MEP. We shall see how far I get with this. Help always appreciated, especially as I have MEP 22 and 27 to finish for 2.1 once 1.5 lands. |
Sorry, something went wrong.
|
See #12419 where I moved this PR (couldn't see force pushing here as viable) |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Working implementation of a PiecewiseLinearNorm, including a DivergingNorm subclass.
All the tests from the @dopplershift and @phobson at present pass apart from the tests that have norms that don't monotonically increase (i.e. they stay static) e.g. where vmin=vcenter and/or vcenter=vmax.
Should we allow this or not?