matplotlib-devel Mailing List for matplotlib

Hi
Thank you that solves the problem we had.
I'm sorry for posting this on the development list, it was intended for the
users list, and I somehow entered the wrong address.
Regards
Pål
On 7 July 2013 21:44, Eric Firing <ef...@ha...> wrote:
> On 2013年07月04日 11:43 PM, Pål Gunnar Ellingsen wrote:
> > Hi
> >
> > I'm having some problems with the formatter of ticks in a polar plot.
> > Below is a minimum example
> > The first figure is correct, the second has wrong ticks.
> >
> > This has be tested both on 1.2.0 and the latest from git (1.4.x, commit
> > 64cc3416396ffb2811af80fc810ed63572df71d9 )
> >
> > Does anyone know whys this happens?
> > Is it a bug in MaxNLocator
>
> No, it is a misunderstanding of how the colorbar works. It's long axis
> is using its own units, and it maps the color scale to those units.
> Therefore, one should not try to manipulate the axis properties
> directly. Below I show two altered lines and one deletion. I think
> this will produce what you want.
>
> >
> > Kind regards
> >
> > Pål
> >
> > ---------------------------
> > #!/usr/bin/env python
> >
> > import numpy as np
> > import matplotlib.pyplot as plt
> > from matplotlib.ticker import MaxNLocator
> >
> > # Data
> > M=np.sin(np.meshgrid(np.arange(30),np.arange(30)))
> > M=np.squeeze(M[0,:,:])
> > Radius=np.arange(30)
> > Theta=np.arange(30)
> >
> > # Plotting the correct figure
> > print('Correct ticks')
> > fig=plt.figure()
> > ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
> > c = ax1.pcolormesh(Theta, Radius, M)
> > ax1.set_frame_on(False)
> > plt.xticks([])
> > plt.yticks([])
> > ax2=fig.add_axes([0.9,0.1,0.05,0.7])
> > cb=fig.colorbar(c,cax=ax2)
> > plt.show()
> >
> > # Doing the same plot
> > print('Wrong ticks by using formatter')
> > fig=plt.figure()
> > ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
> #> c = ax1.pcolormesh(Theta, Radius, M)
>
> c = ax1.pcolormesh(Theta, Radius, M, vmin=-1, vmax=1)
>
> > ax1.set_frame_on(False)
> > plt.xticks([])
> > plt.yticks([])
> > ax2=fig.add_axes([0.9,0.1,0.05,0.7])
> #> cb=fig.colorbar(c,cax=ax2)
>
> cb = fig.colorbar(c, cax=ax2, ticks=MaxNLocator(3))
>
> >
> #> # except now setting a limit to the number of ticks using a formatter
> #> # which results in wrong ticks
> #> cb.ax.yaxis.set_major_locator(MaxNLocator(3))
>
> > plt.show()
>
> Eric
>
> > -----------------------
> >
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Sun, Jul 7, 2013 at 10:14 PM, Tony Yu <ts...@gm...> wrote:
> Hi David,
>
> Sorry for the delay in replying. It was good meeting you last week.
> Comments inline with a lot of parts cut out.
>
Hi Tony,
It was great to meet you too!
>
>
> On Thu, Jul 4, 2013 at 10:13 PM, David P. Sanders <dps...@gm...>wrote:
>>
>> I have been working, as a first step, on colored line support. This is
>> not, of course, new -- it's all in LineCollection. However, as a user,
>> LineCollection is intimidating and difficult to understand, and does not
>> lead to easy experimentation (I speak from experience).
>>
>
> I agree that LineCollection isn't the most user-friendly thing to use.
> Personally, I'd be in favor of something like your `linecolor` suggestion,
> but I'd understand if the core-devs have concerns about feature creep.
>
Yes, I do understand your point, but I feel strongly that providing simple
interfaces for otherwise complicated concepts / syntax is important, and
very much in the spirit of matplotlib as I understand it.
>
>
>> At Tony's suggestion, the first step was to rewrite the
>> multicolored_line.py example.
>> You can find my first attempt as an IPython notebook at
>>
>>
>> https://github.com/dpsanders/matplotlib-examples/blob/master/linecolor.ipynb
>>
>> or
>>
>>
>> http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/matplotlib-examples/master/linecolor.ipynb
>>
>
> This looked pretty interesting when I first looked at it, but it seems to
> be down now.
>
Apologies, I decided that 'colorline' was a better name than 'linecolor'
(since 'colorline' suggests that we are going to color a line, i.e. it puts
the verb and the noun in the correct order!), so I changed the notebook to
https://github.com/dpsanders/matplotlib-examples/blob/master/colorline.ipynb
http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/matplotlib-examples/master/colorline.ipynb
>
>
>> Please let me have any comments before I attempt the next step of making
>> a pull request.
>>
>
I am trying to get to making a pull request, but am having trouble
incorporating the plot correctly into the gallery:
I have been trying to include colorline.py in the correct place in the
examples tree to have it added automatically to the gallery.
Somebody (don't remember who exactly -- Mike?) showed me how to do this
during the sprint, but I have been unable to reproduce the steps
successfully.
Could you please remind me exactly where I should put the file, and what
the correct sequence of commands to execute is? Is there a special format
that the file should have? For example, it seems that it should only have
one plt.show() following the other examples with multiple plots -- is
that right?
(I once managed to get a single one of the plots to show in the gallery,
and have not been able to reproduce that feat since!)
> It seems to me that IPython notebooks are quite a natural format for
>> such examples, especially with a view to having interactive examples in the
>> future.
>>
>
> Using IPython notebooks as examples would be really beneficial in the long
> run, as discussed during the BoF. I struggled with implementing support for
> interleaved text, code, and plots for the scikit-image gallery (so that
> examples could have real explanations). IPython notebooks are a more
> natural format for this, but they're not quite there yet---specifically
> nbconvert is still evolving (though this should be integrated into the next
> release). That said, someone will need to write the code that takes the
> output from nbconvert and integrates it with the current Sphinx code that
> generates the gallery. Most of this will be straightforward but tedious.
>
The current git master of ipython indeed has nbconvert integrated. The
Python script output is also in my git repository -- these kind of outputs
should be easy to parse.
(Though I personally have no idea where to even start with something like
that. Any suggestions? Is there some kind of standard package for this kind
of thing?)
>
>
>> What is the situation with tagging the examples? If the examples are
>> being refactored, it would seem to at least be a natural moment to start
>> adding tags, even if nothing is actually done with them yet.
>>
>
> This is a great idea. I wish I had suggested this in my original MEP. I'm
> not sure if there's been progress on adding an interface for tags, but we
> should be adding tags during any clean ups to the examples so they're ready
> in the
>
I agree that it should be added to the MEP. From my point of view, the
exact tags that should be used may well be something that evolves over time.
>
> - Also during the BoF / sprint, style sheets were discussed several times.
>> Tony seems to have already solved this problem in his mpltools package --
>> I would suggest that this could be brought straight into Matplotlib?
>>
>
> This was my original plan. At the time I wrote the original, the rc parser
> wasn't exposed to the user. That's been fixed now, but I haven't found the
> time to integrate changes into Matplotlib proper. If anyone else would like
> to have a go at it, they are more than welcome. Otherwise, I'll get to it
> at some point ... hopefully.
>
OK, great.
Best,
David.
>
> Cheers!
> -Tony
>
-- 
**************************************************************************
Dr. David P. Sanders
Profesor Titular A / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)
dps...@gm...
http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414
Tel.: +52 55 5622 4965

Hi David,
Sorry for the delay in replying. It was good meeting you last week.
Comments inline with a lot of parts cut out.
On Thu, Jul 4, 2013 at 10:13 PM, David P. Sanders <dps...@gm...>wrote:
>
> I have been working, as a first step, on colored line support. This is
> not, of course, new -- it's all in LineCollection. However, as a user,
> LineCollection is intimidating and difficult to understand, and does not
> lead to easy experimentation (I speak from experience).
>
I agree that LineCollection isn't the most user-friendly thing to use.
Personally, I'd be in favor of something like your `linecolor` suggestion,
but I'd understand if the core-devs have concerns about feature creep.
> At Tony's suggestion, the first step was to rewrite the
> multicolored_line.py example.
> You can find my first attempt as an IPython notebook at
>
>
> https://github.com/dpsanders/matplotlib-examples/blob/master/linecolor.ipynb
>
> or
>
>
> http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/matplotlib-examples/master/linecolor.ipynb
>
This looked pretty interesting when I first looked at it, but it seems to
be down now.
> Please let me have any comments before I attempt the next step of making a
> pull request.
> It seems to me that IPython notebooks are quite a natural format for such
> examples, especially with a view to having interactive examples in the
> future.
>
Using IPython notebooks as examples would be really beneficial in the long
run, as discussed during the BoF. I struggled with implementing support for
interleaved text, code, and plots for the scikit-image gallery (so that
examples could have real explanations). IPython notebooks are a more
natural format for this, but they're not quite there yet---specifically
nbconvert is still evolving (though this should be integrated into the next
release). That said, someone will need to write the code that takes the
output from nbconvert and integrates it with the current Sphinx code that
generates the gallery. Most of this will be straightforward but tedious.
> What is the situation with tagging the examples? If the examples are being
> refactored, it would seem to at least be a natural moment to start adding
> tags, even if nothing is actually done with them yet.
>
This is a great idea. I wish I had suggested this in my original MEP. I'm
not sure if there's been progress on adding an interface for tags, but we
should be adding tags during any clean ups to the examples so they're ready
in the future.
- Also during the BoF / sprint, style sheets were discussed several times.
> Tony seems to have already solved this problem in his mpltools package --
> I would suggest that this could be brought straight into Matplotlib?
>
This was my original plan. At the time I wrote the original, the rc parser
wasn't exposed to the user. That's been fixed now, but I haven't found the
time to integrate changes into Matplotlib proper. If anyone else would like
to have a go at it, they are more than welcome. Otherwise, I'll get to it
at some point ... hopefully.
Cheers!
-Tony