No need for i: for ax_row, (norm, title) in zip(axes, normalizations):

great idea :)

I don't understand why the data needs to be produced in the loop if it's just going to be cached. Seems a bit over-engineered for an example.

Yes, you are right, the reason it is like this is because originally each of the plots was done independently inside a function, but I changed it a loop to comply with feedback from @story645, and I forgot to change that, thanks :)

max or vmax?

This should be **kwargs.

I understand that kwargs is what is used as the general case, however, I used normalize_kw because all of these parameters are to be passed to the parent class Normalize. This is the same name convention used for subplots.

That's not the same; those are dictionaries that are individual arguments. In this case, it's not an argument, it's the placeholder that accepts all other non-explicit keyword arguments.

You are completely right. In that case I am thinking that it may just be better to get vmin, and vmax and clip directly, and pass them explicitly to the parent class. Any downside to doing it like that_

We should probably just follow the example of the other classes; LogNorm, BoundaryNorm and NoNorm only accept clip and the rest accept all three explicitly, so being explicit seems to be the best choice.

Actually LogNorm does not have a initialization function, so implicitly takes all three of them as well. So yes, I am convinced that it may be better to include them explicitly. It may be worth in that case to put the documentation for vmin, vmax, and clip in common variables so it can be reused across different classes, similarly to what they do here.

It may be a dict in this function, but it's just all-other-keyword-args to any caller.

Agree with @QuLogic that these should be individually documented.

Why is it a MaskedArray? Is that just what other Norms do? It doesn't seem like anything is actually masked.

Precisely, the parent class returns masked arrays, even though it does not really ever sets the mask to anything. It would make sense to use them for values outside the range, the problem is that in that case there would not be a way to say whether they are above the maximum value, or below the minimum, and the plotting methods need this to use the under and over colours.

Would it be useful to cache any of these?

I have been considering this but the problem is that the cache would depend on vmin, and vmax, and checking whether the cache is up to date, along as having to include new variables for the cache, would make the code much uglier.

I guess it would make sense in cases when evaluating f is expensive, but even in those cases, we would still have to evaluate f(result), which typically will consist on many values. Also, in general, the functions typically used for normalization should not be very expensive to evaluate... (although we should never underestimate the user, hehehe)

This appears unused?

Oh, yes, this was used by some of the derived classes in the original PR, and I figured this was the best place for all of them to have access as it is a general purpose normalization feature. I will remove it for now, and then when can decide where to include when it is necessary for the first time.

This is the same vmax you would get if you didn't set it, so I guess it doesn't really test that it's working.

Yes, but that is a test on itself :P
You are right though, I will include tests where the values go above and below vmin, vmax, with and without the clip option.

I have added added test_clip_true, test_clip_false, test_clip__default_false to test the clipping behavior.

Those changes should pretty much address the original comment

Not sure about the mixing of concerns here, but I'll leave that to @efiring to determine.

Yeah, I also was not sure of this, because technically vmin, and vmax, do not belong to this class. Actually the only thing my autoscale methods do differently is to convert to float, so maybe I should just make a tiny change to the autoscale methods of Normalize to resemble this:

Methods in Normalize:

    def autoscale(self, A):
        self.vmin = np.ma.min(A)
        self.vmax = np.ma.max(A)

    def autoscale_None(self, A):
        ' autoscale only None-valued vmin or vmax'
        if self.vmin is None and np.size(A) > 0:
            self.vmin = np.ma.min(A)
        if self.vmax is None and np.size(A) > 0:
            self.vmax = np.ma.max(A)

Methods in FuncNorm:

    def autoscale(self, A):
        self.vmin = float(np.ma.min(A))
        self.vmax = float(np.ma.max(A))

    def autoscale_None(self, A):
        if self.vmin is None:
            self.vmin = float(np.ma.min(A))
        if self.vmax is None:
            self.vmax = float(np.ma.max(A))
        self.vmin = float(self.vmin)
        self.vmax = float(self.vmax)
        if self.vmin > self.vmax:
            raise ValueError("vmin must be smaller than vmax")

@efiring would it be ok, to include those changes (casting to float and vmax>vmin check) in Normalize, and remove the methods from FuncNorm?

feel like this should be in a main block, and might as well just directly put all the plotting code there instead of shoving it into a function...so

if __name__ == '__main__':
    all the code currently in main()

The reason I did not do the main originally, is because we now the examples generate the figures automatically through some process, and @efiring and I were not sure whether the actual process would run the file as main.

Yeah of course, I guess the only reason to have things in function is so the data generation could be after the rest, but maybe now that is much shortened it will not look that bad right in between were the norms are generated, and where the loop starts.

The vast majority of examples (like >90%) use neither main, nor __main__ stuff, though I'm sure some examples use classes derived from backend-specific things that I didn't count properly.

extraneous comment 'cause code explicitly shows this

this comment should be dropped and there should be a standalone example for that feature

same as above, presenting users with 3 ways to do things off the bat can be super confusing. Also, is it really necessary to use two examples of the same norm in 1 example? I know you'll likely tell me it's more realistic, but I think examples should fundementally as small/basic as possible while still showing the functionality

two examples of the same norm in 1 example?

If you're referring to the two Axes, one is the norm function, the other is the actual usage for a colormap; see the figure at the top.

I do not really see a problem of having an example of multiple use in this case (both the log, and the sqrt), but I am happy to change it if everyone thinks that the example image is not appropriate.

I also think that presenting multiple ways of doing the same thing (with the extra comment) provides the user an extra insight of what it can be done with the class, at a very low cost. But again, if everyone agrees that the comments are inappropriate, I am also happy to remove them.

@QuLogic I was talking about the log and the sqrt norms and then also providing multiple methods of doing things. @alvarosg is there a colleague you can "hallway test" these docs (and warning messages) with. You have them read the doc/message and just ask what they think (and how they think it could be improved)

f must be a function or a string (I don't like using callable in user facing docs 'cause I think it's a little too dev space)

I always the user of a python module will also be a developer, and callable is a keyword of python, so IMO it is more clearer than function.

That's not true at all though in this case. You've got plenty of users for matplotlib in particular who are scientists but not devs who aren't gonna be familiar with any python keyword they don't use all the time (and callable is rarely in that set)

I think that at least when they are native English speakers they can figure it out quickly enough from the context and the structure of the word itself, "callable" -> "call" "able" -> "something that can be called". The word "string" would be much harder to understand than "callable"--it's pure comp-sci jargon, not used anywhere else in this way, and not something that can be figured out from the word itself. We are not going to delete uses of "string" or "callable".

Callable is equivalent to function.. You'd still need to mention it was a string. And string is different cause it's used in every single intro python everything, callable isn't. Honestly, callable trips me up all the time and I'm a native English speaker with a CS background.

Basically, I dunno I see your point but a) I'm always wary of straight transcriptions of the if statements that triggered the exceptions being the error messages b) I sort of think their should maybe be a bigger discussion of who is matplotlib's expected audience.

I would leave it callable, because I think is a more accurate term. I think anyone able to use a callable (to pass it to the function) should know the term, and if not should be able to do a 5 s google search. In any case, let´s not waste our energy discussion this, as I think it is pretty irrelevant.

While I agree with you that this specific thing probably isn't worth fighting about, I feel in a general sense that it's bad practice to dismiss a usability concern as "well they should know what it's called and how to search for it" 'cause rarely are either of those statements true.

any particular reason this is put at the end rather than upfront?

Nope, I will move it up

does self.vmin/self.vmin need to be converted to float? I think there's an import at the top that forces division to always be floating point...

This is a very good point, I did not noticed that, I guess there is no need, in that case. Thanks!

What about something like this 'cause I feel like this is a bit too much on the clever but obfuscating side?
mask = mask_over || mask_under
and then just use ~mask everywhere you're using mask.

Or mask = ~(mask_over | mask_under) or mask = ~mask_over & ~mask_under?

Sure, I am always up for improving the efficiency!

Same as @QuLogic , question for @efiring about mixing concerns. Wonder if all the tick stuff should be in a private class (or public) in ticker and then normalize should just point to the default formatter and locators it should use. (this is an issue I ran headlong into w/ catagorical norming too...)

Yes, I am definitely not very happy with the current with this the way it is...

and then normalize should just point to the default formatter and locators it should use

How does Normalize communicates with the formatters and tickers, is there any good example around?

How does Normalize communicates with the formatters and tickers, is there any good example around?

It's really messy currently (code is in colorbar.py and would probably require a refactor in the call stack. But that doesn't really matter to you. Since you're having them explictly get ticks via

ticks = cax.norm.ticks(5) if norm else np.linspace(0, 1, 6) 
fig.colorbar(cax, format='%.3g', ticks=ticks, ax=ax_right)

cax.norm.ticks should really likely be it's own tick Locator Method that locates ticks based on some input (I guess convoluted functions). The downside is that it can't rely on the attributes in the norm (unless it's something like FuncNormLocator(norm)), but I think that prevents scope creep in norms.

Yes, but I ideally I would not like the user to have to call ticks manually, but to get those ticks automatically, but I was not sure how to change the default ticker, to maybe implement a FuncTicker class...

It would be easy to modify colorbar to use the ticks method of its Norm, if it exists, and if ticks are not provided by the user. The alternative of having all tick locators and formatters in tickers.py, and having Norms include a method or attributes for default locators and formatters, is also reasonable. I'm going to leave this question open for the moment, but we will need to return to it. I suspect the second of these two approaches will turn out to be the best.

Yes, it would, but the problem is that the colorbar has two different ways to represent the colorbar, depending on spacing:

• 'uniform': Represent the colorbar uniformly between 0 and 1 and then assign values for the ticks that are not uniform according to the normalization. This is the one I normally use, and the ones that should use the tick values returned by ticks.
• 'proportional': Stretch/compress the colorbar to represent the non-linearities given by the normalization, so the actual axis in the colorbar is uniform on the data values. In this case selecting the ticks is the same as with any linear axis.

What if I just make a FuncNorm locator class, and then add the corresponding line here?

@efiring @story645 I have now made a new class FuncLocator (And tests), to include the behavior of proposing tick locations in a more appropriate place.

Instead of taking the norm itself as a parameter of the locator, I decided to just pass a method with the direct and inverse transformation. Then references to the methods of the norm object are passed in the initialization. This way the ticker module does not depend directly on colors, and on FuncNorm in particular, but still, if the FuncNorm instance is modified (limits for example, after calling clim), FuncNorm will adapt the behaviour if his methods and this will be available to the locator.

If you could please take a look, I am sure you can provide useful feedback.

PS: Happy new year :D

The indent is kind of funny here; I'd break before the gridspec_kw, not in the middle of its value, if possible. Also, you can add sharex='col' and this will automatically remove the tick labels in between plots.

Add tests for scalar values

this is now added