Re: [Matplotlib-users] colorbar.Colorbar ticking

Friedrich Romstedt wrote:
> 2010/3/29 Eric Firing <ef...@ha...>:
>> It already has this.  You can pass in a custom locator or set of tick
>> locations via the "ticks" kwarg, but if you don't, a locator is chosen
>> automatically.  Except in special cases, this will be a MaxNLocator. See the
>> ColorbarBase._ticker method.
> 
> Ah, thanks, It escaped my notice that there is a toplevel "if
> self.locator is None:" statement ... ok.
> 
>> Ah, maybe what you mean is a text option to the "ticks" kwarg that would
>> specify MaxNLocator without requiring one to instantiate a MaxNLocator? I
>> don't think this makes sense for the case when boundaries are specified
>> explicitly.
> 
> No, what I intended is exactly what you pointed out.
> 
> Btw, can you tell me what the *values* kwarg's semantic is?  I guess,
> it shall be the center values of the values displayed, but then the
> implementation for this in ColorbarBase._process_values() would be
> broken.

The ColorbarBase simply makes a strip of colored blocks, with their 
sizes and locations determined by the boundaries kwarg (together with 
the "spacing" kwarg) and their colors determined from the values kwarg 
via color mapping.  If either or both of these kwargs is None, the 
boundaries and/or values will be generated  in _process_values.  The use 
of the non-default values kwarg is illustrated by the special-case 
handling of colorbars for contouring in the Colorbar class.

Can you give a test case showing a problem with _process_values?

> 
> Friedrich
> 
> P.S.: I assume you have be caught by the "misconfiguration" of the
> list that the sender is used as the default recipient, so I post back
> to the list?

The mpl lists have been unusual (at least compared to lists for numpy, 
scipy, and cython) in this respect for years.  Usually I remember to 
reply to all, but you are right--this time I goofed.

Eric