matplotlib-users — Discussion related to using matplotlib

[Matplotlib-users] xlabels on top, ylabels on right

[Andreas H. <li...@hi...>]

Hi, me again :)

I'm looking for a way to have the xlabels on the top (instead of bottom),
and the ylabels on the right (instead of left). I guess I could do
something with twinx / twiny and just not use the left/bottom axis, but
I'm sure there is some more elegant way ...

Cheers, Andreas.

[Matplotlib-users] x-label location not at xtick location?

[Andreas H. <li...@hi...>]

Hi,

another question. Given the plot from my last email (I attached the code
to this one as well), I would like to have the x-labels ("J", "F", ...)
not at the location of the xticks, but centered in between to xticks. I
would then move the xticks so that they form the bins to the data chunks,
and the labels should be where the current xticks are.

Any suggestions are again extremely welcome :)

Cheers, Andreas.

[Matplotlib-users] color pallette suggestions wanted

[Andreas H. <li...@hi...>]

Hi,

I have some data I want to plot using pcolormesh. It's 2d climatological
data, see the attached plot. My data is in a range from -7 to +0.6. I want
to be 0.0 to be clearly visible, while at the same time, the color range
should show the full dynamic of the values. I played with the bwr and
seismic color maps, centering on zero, so that white is 0.0. However, I'm
not too happy with the dynamic range I get in the negative.

Any suggestions are very welcome ...

Cheers, Andreas.

Re: [Matplotlib-users] Format date tick labels

[Damon M. <dam...@gm...>]

On Thursday, October 11, 2012, Benjamin Root wrote:

>
>
> On Thu, Oct 11, 2012 at 4:53 PM, Mark Lawrence <bre...@ya...<javascript:_e({}, 'cvml', 'bre...@ya...');>
> > wrote:
>
>> On 11/10/2012 10:55, Damon McDougall wrote:
>> > On Wed, Oct 10, 2012 at 5:00 PM, Benjamin Root <ben...@ou...<javascript:_e({}, 'cvml', 'ben...@ou...');>>
>> wrote:
>> >>
>> >>
>> >> On Wed, Oct 10, 2012 at 10:55 AM, Mark Lawrence <
>> bre...@ya... <javascript:_e({}, 'cvml',
>> 'bre...@ya...');>>
>> >> wrote:
>> >>>
>> >>> On 10/10/2012 15:41, Mark Lawrence wrote:
>> >>>> On 10/10/2012 14:29, Benjamin Root wrote:
>> >>>>>
>> >>>>> I know of a few people who have difficulties with matplotlib's
>> datetime
>> >>>>> handling, but they are usually operating on the scale of
>> milliseconds
>> >>>>> or
>> >>>>> less (lightning data), in which case, one is already at the edge of
>> the
>> >>>>> resolution handled by python's datetime objects.  However, we would
>> >>>>> certainly welcome any sort of examples of how matplotlib fails in
>> >>>>> handling
>> >>>>> seconds scale and lower plots.
>> >>>>>
>> >>>>> Cheers!
>> >>>>> Ben Root
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> I'll assume that the milliseconds above is a typo.  From
>> >>>> http://docs.python.org/library/datetime.html "class
>> datetime.timedelta A
>> >>>> duration expressing the difference between two date, time, or
>> datetime
>> >>>> instances to microsecond resolution."  Still, what's a factor of 1000
>> >>>> amongst friends? :)
>> >>>>
>> >>>
>> >>> http://www.python.org/dev/peps/pep-0418/ has been implemented in
>> Python
>> >>> 3.3 and talks about clocks with nanosecond resolutions.  I've flagged
>> it
>> >>> up here just in case people weren't aware.
>> >>>
>> >>
>> >> Ah, you are right, I meant microseconds.
>> >>
>> >> With apologies to Spaceballs:
>> >>
>> >> "Prepare to go to microsecond resolution!"
>> >> "No, no, microsecond resolution is too slow"
>> >> "Microsecond resolution is too slow?"
>> >> "Yes, too slow. We must use nanosecond resolution!"
>> >> "Prep-- Prepare Python, for nanosecond resolution!"
>> >>
>> >> Cheers!
>> >> Ben Root
>> >
>> > Am I missing something here? Are seconds just floats internally? A
>> > delta of 1e-6 is nothing (pardon the pun). A delta of 1e-9 is the
>> > *least* I'd expect. Maybe even 1e-12. Perhaps the python interpreter
>> > doesn't do any denormalising<
>> http://stackoverflow.com/questions/9314534/why-does-changing-0-1f-to-0-slow-down-performance-by-10x
>> >
>> > when encountered with deltas very close to zero...
>> >
>>
>> What percentage of computer users wants a delta of 1e-12?  I suspect
>> that the vast majority of users couldn't care two hoots about miniscule
>> time deltas in a world where changing time zones can cause chaos.  Where
>> some applications cannot handle years before 1970, or 1904, or 1900 or
>> whatever.  Or they can't go too far forward, 2036 I think but don't
>> quote me.  Where people like myself had to put a huge amount of effort
>> into changing code so that applications would carry on working when the
>> date flipped over from 31st December 1999 to 1st January 2000.  If
>> things were that simple why is matplotlib using third party modules like
>> dateutil and pytz?  Why doesn't the "batteries included" Python already
>> provide this functionality?
>>
>>
> Preach on, my brother! Preach on!
>
> [psst -- you are facing the choir...]
>
> Cheers!
> Ben Root
>
>
Clearly I have misunderstood something and hit a nerve. Apologies.


-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [Matplotlib-users] trouble switching off smoothing in imshow()

[Eric F. <ef...@ha...>]

On 2012/10/10 3:07 AM, Anand Sivaramakrishnan wrote:
> Thanks for the many useful responses - I eventuallyfound by experiment
> that imshow(  interpolation='nearest' works *if* I write a png file.
> Saving a pdf file mushed up my crisp pixel boundaries.  However, saving
> as png, then using (mac osx) preview to convert to pdf worked fine.
> Go figure()!

This doesn't seem right to me, that pdf would be "mushed".  Would you 
supply an example, please?  Ideally a simple script with the png result 
and the mpl pdf result?

Eric

>
>>
>>
>>     I have solved this problem earlier using figimage(), but that was
>>     a lot of work (I had to create a pixel-by-pixel array with all
>>     greyscale values set myself, and then I was working in pixel
>>     coordinates rather than my data coordinates).  Has anyone figured
>>     out how to get imshow to stop smoothing the image?  Using imshow(…
>>     interpolation='none'…) or imshow(… interpolation=None…) raise
>>     exceptions.
>>
>>     I found NonUniformImage too hard to figure out from the documentation.
>>
>>     ------------------------------------------------------------------------------
>>     Don't let slow site performance ruin your business. Deploy New
>>     Relic APM
>>     Deploy New Relic app performance management and know exactly
>>     what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>     Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>     http://p.sf.net/sfu/newrelic-dev2dev
>>     _______________________________________________
>>     Matplotlib-users mailing list
>>     Mat...@li...
>>     <mailto:Mat...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Re: [Matplotlib-users] dpi

[Jae-Joon L. <lee...@gm...>]

On Fri, Oct 12, 2012 at 3:39 AM, Nikolaus Rath <Nik...@ra...> wrote:
> matplotlib actually rescales the raw imshow data when saving to a vector
> format? Why is that? I think it should embed the bitmap with full
> resolution in the vector file and rely on the consumer of the vector
> file to scale it to whatever resolution is supported by the display
> device.

imshow supports interpolation and that's why rasterization comes in.
If you turn off interpolation (w/ interpolation="none"), the original
image will be embedded. Of course dpi has no meaning in this case.

However, I agree with you that dpi should be a property of the backend
only, not the figure. But I am not sure if this can be fixed soon. It
will be difficult and will take lots of effort I think.

-JJ

Re: [Matplotlib-users] Pylab import error due to dateutil

[Michael D. <md...@st...>]

Thanks for taking this on, Damon and Gökhan.

Note this will need to create a different symlink (to dateutil_py3 
instead) on Python 3.  This means, of course, that it will be impossible 
to develop on both Python 2 and 3 simultaneously, but that's true of 
"setuptools' develop" in any event, so it's no great loss.

Mike

On 10/11/2012 03:38 PM, Damon McDougall wrote:
> On Thu, Oct 11, 2012 at 9:25 PM, Gökhan Sever <gok...@gm...> wrote:
>> I am not sure about that technical detail, but it works fine here on my
>> Fedora 16 (x86_64) system.
>>
>>
>> On Thu, Oct 11, 2012 at 11:04 AM, Damon McDougall
>> <dam...@gm...> wrote:
>>>
>>>
>>> On Thursday, October 11, 2012, Gökhan Sever wrote:
>>>>
>>>>
>>>> On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall
>>>> <dam...@gm...> wrote:
>>>>>
>>>>> Gökhan, did you implement the symlink fix? If so, would you mind
>>>>> making a pull request out of it? I was just about to look into doing
>>>>> this, but if you've done it already that'd save us some effort rolling
>>>>> out fixes for 1.2.
>>>>>
>>>>> Cheers.
>>>>> Damon
>>>>
>>>>
>>>> Hi Damon,
>>>>
>>>> I think adding these lines before execfile line in setupegg.py should fix
>>>> it:
>>>>
>>>> import os
>>>> os.chdir('lib')
>>>> if not os.path.isdir('dateutil'):
>>>>      os.symlink('dateutil_py2', 'dateutil')
>>>> os.chdir('..')
>>>>
>>>>
>>>> Could you give it a test? Do we require a similar symlink for py3?
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> --
>>>> Gökhan
>>>
>>> Awesome. I'll give it a go later on. I'm a little concerned using
>>> os.chdir. I think Peter Wuertz/Chris Gohlke had problems with it not being
>>> threadsafe on windows. Does the same apply here?
> I'm not sure how to test this. I'm running `setupegg.py develop` from
> within a python virtual env, but somehow it's picking up dateutil
> version 1.5. I don't get the `matplotlib will provide` message... Hmm.
>

Re: [Matplotlib-users] Format date tick labels

[Benjamin R. <ben...@ou...>]

On Thu, Oct 11, 2012 at 4:53 PM, Mark Lawrence <bre...@ya...>wrote:

> On 11/10/2012 10:55, Damon McDougall wrote:
> > On Wed, Oct 10, 2012 at 5:00 PM, Benjamin Root <ben...@ou...> wrote:
> >>
> >>
> >> On Wed, Oct 10, 2012 at 10:55 AM, Mark Lawrence <
> bre...@ya...>
> >> wrote:
> >>>
> >>> On 10/10/2012 15:41, Mark Lawrence wrote:
> >>>> On 10/10/2012 14:29, Benjamin Root wrote:
> >>>>>
> >>>>> I know of a few people who have difficulties with matplotlib's
> datetime
> >>>>> handling, but they are usually operating on the scale of milliseconds
> >>>>> or
> >>>>> less (lightning data), in which case, one is already at the edge of
> the
> >>>>> resolution handled by python's datetime objects.  However, we would
> >>>>> certainly welcome any sort of examples of how matplotlib fails in
> >>>>> handling
> >>>>> seconds scale and lower plots.
> >>>>>
> >>>>> Cheers!
> >>>>> Ben Root
> >>>>>
> >>>>>
> >>>>
> >>>> I'll assume that the milliseconds above is a typo.  From
> >>>> http://docs.python.org/library/datetime.html "class
> datetime.timedelta A
> >>>> duration expressing the difference between two date, time, or datetime
> >>>> instances to microsecond resolution."  Still, what's a factor of 1000
> >>>> amongst friends? :)
> >>>>
> >>>
> >>> http://www.python.org/dev/peps/pep-0418/ has been implemented in
> Python
> >>> 3.3 and talks about clocks with nanosecond resolutions.  I've flagged
> it
> >>> up here just in case people weren't aware.
> >>>
> >>
> >> Ah, you are right, I meant microseconds.
> >>
> >> With apologies to Spaceballs:
> >>
> >> "Prepare to go to microsecond resolution!"
> >> "No, no, microsecond resolution is too slow"
> >> "Microsecond resolution is too slow?"
> >> "Yes, too slow. We must use nanosecond resolution!"
> >> "Prep-- Prepare Python, for nanosecond resolution!"
> >>
> >> Cheers!
> >> Ben Root
> >
> > Am I missing something here? Are seconds just floats internally? A
> > delta of 1e-6 is nothing (pardon the pun). A delta of 1e-9 is the
> > *least* I'd expect. Maybe even 1e-12. Perhaps the python interpreter
> > doesn't do any denormalising<
> http://stackoverflow.com/questions/9314534/why-does-changing-0-1f-to-0-slow-down-performance-by-10x
> >
> > when encountered with deltas very close to zero...
> >
>
> What percentage of computer users wants a delta of 1e-12?  I suspect
> that the vast majority of users couldn't care two hoots about miniscule
> time deltas in a world where changing time zones can cause chaos.  Where
> some applications cannot handle years before 1970, or 1904, or 1900 or
> whatever.  Or they can't go too far forward, 2036 I think but don't
> quote me.  Where people like myself had to put a huge amount of effort
> into changing code so that applications would carry on working when the
> date flipped over from 31st December 1999 to 1st January 2000.  If
> things were that simple why is matplotlib using third party modules like
> dateutil and pytz?  Why doesn't the "batteries included" Python already
> provide this functionality?
>
>
Preach on, my brother! Preach on!

[psst -- you are facing the choir...]

Cheers!
Ben Root

Re: [Matplotlib-users] Format date tick labels

[Mark L. <bre...@ya...>]

On 11/10/2012 10:55, Damon McDougall wrote:
> On Wed, Oct 10, 2012 at 5:00 PM, Benjamin Root <ben...@ou...> wrote:
>>
>>
>> On Wed, Oct 10, 2012 at 10:55 AM, Mark Lawrence <bre...@ya...>
>> wrote:
>>>
>>> On 10/10/2012 15:41, Mark Lawrence wrote:
>>>> On 10/10/2012 14:29, Benjamin Root wrote:
>>>>>
>>>>> I know of a few people who have difficulties with matplotlib's datetime
>>>>> handling, but they are usually operating on the scale of milliseconds
>>>>> or
>>>>> less (lightning data), in which case, one is already at the edge of the
>>>>> resolution handled by python's datetime objects.  However, we would
>>>>> certainly welcome any sort of examples of how matplotlib fails in
>>>>> handling
>>>>> seconds scale and lower plots.
>>>>>
>>>>> Cheers!
>>>>> Ben Root
>>>>>
>>>>>
>>>>
>>>> I'll assume that the milliseconds above is a typo.  From
>>>> http://docs.python.org/library/datetime.html "class datetime.timedelta A
>>>> duration expressing the difference between two date, time, or datetime
>>>> instances to microsecond resolution."  Still, what's a factor of 1000
>>>> amongst friends? :)
>>>>
>>>
>>> http://www.python.org/dev/peps/pep-0418/ has been implemented in Python
>>> 3.3 and talks about clocks with nanosecond resolutions.  I've flagged it
>>> up here just in case people weren't aware.
>>>
>>
>> Ah, you are right, I meant microseconds.
>>
>> With apologies to Spaceballs:
>>
>> "Prepare to go to microsecond resolution!"
>> "No, no, microsecond resolution is too slow"
>> "Microsecond resolution is too slow?"
>> "Yes, too slow. We must use nanosecond resolution!"
>> "Prep-- Prepare Python, for nanosecond resolution!"
>>
>> Cheers!
>> Ben Root
>
> Am I missing something here? Are seconds just floats internally? A
> delta of 1e-6 is nothing (pardon the pun). A delta of 1e-9 is the
> *least* I'd expect. Maybe even 1e-12. Perhaps the python interpreter
> doesn't do any denormalising<http://stackoverflow.com/questions/9314534/why-does-changing-0-1f-to-0-slow-down-performance-by-10x>
> when encountered with deltas very close to zero...
>

What percentage of computer users wants a delta of 1e-12?  I suspect 
that the vast majority of users couldn't care two hoots about miniscule 
time deltas in a world where changing time zones can cause chaos.  Where 
some applications cannot handle years before 1970, or 1904, or 1900 or 
whatever.  Or they can't go too far forward, 2036 I think but don't 
quote me.  Where people like myself had to put a huge amount of effort 
into changing code so that applications would carry on working when the 
date flipped over from 31st December 1999 to 1st January 2000.  If 
things were that simple why is matplotlib using third party modules like 
dateutil and pytz?  Why doesn't the "batteries included" Python already 
provide this functionality?

-- 
Cheers.

Mark Lawrence.

Re: [Matplotlib-users] Pylab import error due to dateutil

[Damon M. <dam...@gm...>]

On Thu, Oct 11, 2012 at 9:25 PM, Gökhan Sever <gok...@gm...> wrote:
> I am not sure about that technical detail, but it works fine here on my
> Fedora 16 (x86_64) system.
>
>
> On Thu, Oct 11, 2012 at 11:04 AM, Damon McDougall
> <dam...@gm...> wrote:
>>
>>
>>
>> On Thursday, October 11, 2012, Gökhan Sever wrote:
>>>
>>>
>>>
>>> On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall
>>> <dam...@gm...> wrote:
>>>>
>>>>
>>>> Gökhan, did you implement the symlink fix? If so, would you mind
>>>> making a pull request out of it? I was just about to look into doing
>>>> this, but if you've done it already that'd save us some effort rolling
>>>> out fixes for 1.2.
>>>>
>>>> Cheers.
>>>> Damon
>>>
>>>
>>>
>>> Hi Damon,
>>>
>>> I think adding these lines before execfile line in setupegg.py should fix
>>> it:
>>>
>>> import os
>>> os.chdir('lib')
>>> if not os.path.isdir('dateutil'):
>>>     os.symlink('dateutil_py2', 'dateutil')
>>> os.chdir('..')
>>>
>>>
>>> Could you give it a test? Do we require a similar symlink for py3?
>>>
>>> Thanks.
>>>
>>>
>>> --
>>> Gökhan
>>
>>
>> Awesome. I'll give it a go later on. I'm a little concerned using
>> os.chdir. I think Peter Wuertz/Chris Gohlke had problems with it not being
>> threadsafe on windows. Does the same apply here?

I'm not sure how to test this. I'm running `setupegg.py develop` from
within a python virtual env, but somehow it's picking up dateutil
version 1.5. I don't get the `matplotlib will provide` message... Hmm.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [Matplotlib-users] Pylab import error due to dateutil

[Gökhan S. <gok...@gm...>]

I am not sure about that technical detail, but it works fine here on my
Fedora 16 (x86_64) system.

On Thu, Oct 11, 2012 at 11:04 AM, Damon McDougall <dam...@gm...
> wrote:

>
>
> On Thursday, October 11, 2012, Gökhan Sever wrote:
>
>>
>>
>> On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall <
>> dam...@gm...> wrote:
>>
>>>
>>> Gökhan, did you implement the symlink fix? If so, would you mind
>>> making a pull request out of it? I was just about to look into doing
>>> this, but if you've done it already that'd save us some effort rolling
>>> out fixes for 1.2.
>>>
>>> Cheers.
>>> Damon
>>>
>>
>>
>> Hi Damon,
>>
>> I think adding these lines before execfile line in setupegg.py should fix
>> it:
>>
>> import os
>> os.chdir('lib')
>> if not os.path.isdir('dateutil'):
>>     os.symlink('dateutil_py2', 'dateutil')
>> os.chdir('..')
>>
>>
>> Could you give it a test? Do we require a similar symlink for py3?
>>
>> Thanks.
>>
>>
>> --
>> Gökhan
>>
>
> Awesome. I'll give it a go later on. I'm a little concerned using
> os.chdir. I think Peter Wuertz/Chris Gohlke had problems with it not being
> threadsafe on windows. Does the same apply here?
>
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> B2.39
> Mathematics Institute
> University of Warwick
> Coventry
> West Midlands
> CV4 7AL
> United Kingdom
>



-- 
Gökhan

Re: [Matplotlib-users] XKCD style graphs?

[Juergen H. <py...@el...>]

Am 05.10.2012 11:13, schrieb Matthias BUSSONNIER:
>
> Le 4 oct. 2012 à 23:09, Juergen Hasch a écrit :
>
>> Here is my take on it as an IPython notebook, based on Damon's code:
>> http://nbviewer.ipython.org/3835181/
>>
>> I took the engineering approach and filtered the random function instead of doing some fft/ifft magic.
>> Also, X and Y of the functions are affected now, giving them a more "natural" look in the slopes.
>>
>>    Juergen
>
> If anyone have time to make some examples and a right side thumbnail
> I can make it as featured notebook in the front page of nbviewer.
>
> You can even make a direct PR agains nbviewer and I would then just have
> to merge and deploy.
>
> To be fair, notebook should also give some explanation of the code,
> link to this discussion, maybe show one "original" xkcd graph.
>
> Please take your time, and if there is several submission,
> we'll sort out how to choose the best(s).
>
I automated things a little more, and learned a few things about matplotlib on the way.
Here is the result:
http://nbviewer.ipython.org/3847459/

With xkcd-style.py here:
https://gist.github.com/3874297

Re: [Matplotlib-users] dpi

[Nikolaus R. <Nik...@ra...>]

Damon McDougall <dam...@pu...> writes:
> On Thu, Oct 11, 2012 at 4:00 PM, Nikolaus Rath <Nik...@pu...> wrote:
>> When saving the figure in some vector graphics format, I
>> don't see what the meaning of the dpi is at all.
>
> Sure, I use `dpi=` all the time for vector formats. Purely because
> when you make calls to `imshow`, you get a rasterised image embedded
> in a figure with vector text and tickmarks and labels, for example.

matplotlib actually rescales the raw imshow data when saving to a vector
format? Why is that? I think it should embed the bitmap with full
resolution in the vector file and rely on the consumer of the vector
file to scale it to whatever resolution is supported by the display
device.


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

Re: [Matplotlib-users] Pylab import error due to dateutil

[Damon M. <dam...@gm...>]

On Thursday, October 11, 2012, Gökhan Sever wrote:

>
>
> On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall <
> dam...@gm... <javascript:_e({}, 'cvml',
> 'dam...@gm...');>> wrote:
>
>>
>> Gökhan, did you implement the symlink fix? If so, would you mind
>> making a pull request out of it? I was just about to look into doing
>> this, but if you've done it already that'd save us some effort rolling
>> out fixes for 1.2.
>>
>> Cheers.
>> Damon
>>
>
>
> Hi Damon,
>
> I think adding these lines before execfile line in setupegg.py should fix
> it:
>
> import os
> os.chdir('lib')
> if not os.path.isdir('dateutil'):
>     os.symlink('dateutil_py2', 'dateutil')
> os.chdir('..')
>
>
> Could you give it a test? Do we require a similar symlink for py3?
>
> Thanks.
>
>
> --
> Gökhan
>

Awesome. I'll give it a go later on. I'm a little concerned using os.chdir.
I think Peter Wuertz/Chris Gohlke had problems with it not being threadsafe
on windows. Does the same apply here?


-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [Matplotlib-users] Pylab import error due to dateutil

[Gökhan S. <gok...@gm...>]

On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall
<dam...@gm...>wrote:

>
> Gökhan, did you implement the symlink fix? If so, would you mind
> making a pull request out of it? I was just about to look into doing
> this, but if you've done it already that'd save us some effort rolling
> out fixes for 1.2.
>
> Cheers.
> Damon
>


Hi Damon,

I think adding these lines before execfile line in setupegg.py should fix
it:

import os
os.chdir('lib')
if not os.path.isdir('dateutil'):
    os.symlink('dateutil_py2', 'dateutil')
os.chdir('..')


Could you give it a test? Do we require a similar symlink for py3?

Thanks.


-- 
Gökhan

Re: [Matplotlib-users] dpi

[Damon M. <dam...@gm...>]

On Thu, Oct 11, 2012 at 4:00 PM, Nikolaus Rath <Nik...@ra...> wrote:
> When saving the figure in some vector graphics format, I
> don't see what the meaning of the dpi is at all.

Sure, I use `dpi=` all the time for vector formats. Purely because
when you make calls to `imshow`, you get a rasterised image embedded
in a figure with vector text and tickmarks and labels, for example.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

[Matplotlib-users] dpi

[Nikolaus R. <Nik...@ra...>]

Hello,

I'm confused by the dpi property of figures that can be set in
matplotlibrc or passed to pyplot.figure().

It seems to me that dpi is really a property of the backend, not the
figure, and the only place to specify it ought to be when saving into a
bitmap file. 

For example, when showing a figure on the screen, I really want
matplotlib to use the physical dpi of the monitor rather than any
default value. When saving the figure in some vector graphics format, I
don't see what the meaning of the dpi is at all.

Am I missing something?

Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

Re: [Matplotlib-users] data grid problem

[Damon M. <dam...@gm...>]

On Thu, Oct 11, 2012 at 1:52 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Thursday, October 11, 2012, Damon McDougall wrote:
>>
>> On Wed, Oct 10, 2012 at 3:55 PM, Benjamin Root <ben...@ou...> wrote:
>> >
>> >
>> > On Wed, Oct 10, 2012 at 9:40 AM, rand0m <ra...@0x...> wrote:
>> >>
>> >> Hello,
>> >>
>> >> I'm new to matplotlib and I hope you can help me out with my question.
>> >> When drawing for example a Rectangle() I have to specify it like the
>> >> following:
>> >> rect = Rectangle((1, 3), 2, 20, facecolor="#aaaaaa")
>> >>
>> >> Where 2 is the length and 20 is the height. (1,3) is for xy.
>> >>
>> >> Imagine a coordination system where x-axis should represent the value 0
>> >> to 100. I would like to draw the rectangle from 50 to 60 on x-axis.  So
>> >> I would specify:
>> >>
>> >> rect = Rectangle((50, 3), 10, 20, facecolor="#aaaaaa")
>> >>
>> >> But this does not work as desired because at the xtick 50 the x-axis
>> >> does not "hold" the value 50 but 5 because I made xticks 1-100 with
>> >> step
>> >> 10. So my x-axis "holds" the values 1-10. But I need 1-100.
>> >>
>> >> If anyone knows what Im missing I d be glad to hear about it :-).
>> >>
>> >> thank you
>> >>
>> >
>> > I am not quite sure I understand what you mean.  Can you attach an image
>> > of
>> > the plot you made so far?
>> >
>> > Ben Root
>>
>> I'm not sure if adding a patch autoscales the view, try
>>
>> rect = Rectangle((50, 3), 10, 20, facecolor="#aaaaaa")
>> ax.add_patch(rect)
>> ax.set_xlim(0, 100)
>> ax.set_ylim(0, 25)
>>
>
> We managed to solve it, but apparently it was off-list.  Essentially, I
> showed him how to use a MultipleLocator to control the axis ticks, rather
> than labeling them manually at a different scale.
>
> Ben Root

I thought that might have been the problem. Cheers for the follow-up Ben.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [Matplotlib-users] data grid problem

[Benjamin R. <ben...@ou...>]

On Thursday, October 11, 2012, Damon McDougall wrote:

> On Wed, Oct 10, 2012 at 3:55 PM, Benjamin Root <ben...@ou...<javascript:;>>
> wrote:
> >
> >
> > On Wed, Oct 10, 2012 at 9:40 AM, rand0m <ra...@0x... <javascript:;>>
> wrote:
> >>
> >> Hello,
> >>
> >> I'm new to matplotlib and I hope you can help me out with my question.
> >> When drawing for example a Rectangle() I have to specify it like the
> >> following:
> >> rect = Rectangle((1, 3), 2, 20, facecolor="#aaaaaa")
> >>
> >> Where 2 is the length and 20 is the height. (1,3) is for xy.
> >>
> >> Imagine a coordination system where x-axis should represent the value 0
> >> to 100. I would like to draw the rectangle from 50 to 60 on x-axis.  So
> >> I would specify:
> >>
> >> rect = Rectangle((50, 3), 10, 20, facecolor="#aaaaaa")
> >>
> >> But this does not work as desired because at the xtick 50 the x-axis
> >> does not "hold" the value 50 but 5 because I made xticks 1-100 with step
> >> 10. So my x-axis "holds" the values 1-10. But I need 1-100.
> >>
> >> If anyone knows what Im missing I d be glad to hear about it :-).
> >>
> >> thank you
> >>
> >
> > I am not quite sure I understand what you mean.  Can you attach an image
> of
> > the plot you made so far?
> >
> > Ben Root
>
> I'm not sure if adding a patch autoscales the view, try
>
> rect = Rectangle((50, 3), 10, 20, facecolor="#aaaaaa")
> ax.add_patch(rect)
> ax.set_xlim(0, 100)
> ax.set_ylim(0, 25)
>
>
We managed to solve it, but apparently it was off-list.  Essentially, I
showed him how to use a MultipleLocator to control the axis ticks, rather
than labeling them manually at a different scale.

Ben Root

Re: [Matplotlib-users] trouble switching off smoothing in imshow()

[Damon M. <dam...@gm...>]

On Wed, Oct 10, 2012 at 3:07 PM, Anand Sivaramakrishnan <an...@st...> wrote:
> Thanks for the many useful responses - I eventuallyfound by experiment that
> imshow(  interpolation='nearest' works *if* I write a png file.
> Saving a pdf file mushed up my crisp pixel boundaries.  However, saving as
> png, then using (mac osx) preview to convert to pdf worked fine.

This will almost surely produce a rasterised pdf (tick labels, axes
labels, etc). You may or may not care about this.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [Matplotlib-users] Format date tick labels

[Damon M. <dam...@gm...>]

On Wed, Oct 10, 2012 at 5:00 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, Oct 10, 2012 at 10:55 AM, Mark Lawrence <bre...@ya...>
> wrote:
>>
>> On 10/10/2012 15:41, Mark Lawrence wrote:
>> > On 10/10/2012 14:29, Benjamin Root wrote:
>> >>
>> >> I know of a few people who have difficulties with matplotlib's datetime
>> >> handling, but they are usually operating on the scale of milliseconds
>> >> or
>> >> less (lightning data), in which case, one is already at the edge of the
>> >> resolution handled by python's datetime objects.  However, we would
>> >> certainly welcome any sort of examples of how matplotlib fails in
>> >> handling
>> >> seconds scale and lower plots.
>> >>
>> >> Cheers!
>> >> Ben Root
>> >>
>> >>
>> >
>> > I'll assume that the milliseconds above is a typo.  From
>> > http://docs.python.org/library/datetime.html "class datetime.timedelta A
>> > duration expressing the difference between two date, time, or datetime
>> > instances to microsecond resolution."  Still, what's a factor of 1000
>> > amongst friends? :)
>> >
>>
>> http://www.python.org/dev/peps/pep-0418/ has been implemented in Python
>> 3.3 and talks about clocks with nanosecond resolutions.  I've flagged it
>> up here just in case people weren't aware.
>>
>
> Ah, you are right, I meant microseconds.
>
> With apologies to Spaceballs:
>
> "Prepare to go to microsecond resolution!"
> "No, no, microsecond resolution is too slow"
> "Microsecond resolution is too slow?"
> "Yes, too slow. We must use nanosecond resolution!"
> "Prep-- Prepare Python, for nanosecond resolution!"
>
> Cheers!
> Ben Root

Am I missing something here? Are seconds just floats internally? A
delta of 1e-6 is nothing (pardon the pun). A delta of 1e-9 is the
*least* I'd expect. Maybe even 1e-12. Perhaps the python interpreter
doesn't do any denormalising<http://stackoverflow.com/questions/9314534/why-does-changing-0-1f-to-0-slow-down-performance-by-10x>
when encountered with deltas very close to zero...

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [Matplotlib-users] Pylab import error due to dateutil

[Damon M. <dam...@gm...>]

On Wed, Oct 10, 2012 at 3:09 PM, Michael Droettboom <md...@st...> wrote:
> I filed an issue for this.  We should try to get the fix into 1.2.x
>
> https://github.com/matplotlib/matplotlib/issues/1354
>
> Mike
>
>
> On 10/10/2012 09:00 AM, Michael Droettboom wrote:
>
> I think this stack overflow question [1] sort of sums up the problem --
> setuptools develop is kind of a hack and only really works if the source
> structure matches the installed structure.  That used to be true of
> matplotlib, but installing different packages based on the Python version
> breaks that assumption.
>
> A suggestion in the Stack Overflow entry is to install symlinks to fix this,
> and indeed doing this works:
>
>    cd lib
>    ln -s dateutil_py2 dateutil
>
> We can probably automate this in the setupegg.py script, but I don't think
> I'll have a chance to get to this today.  We can't just include the symlink
> in git, since it should point to the version that corresponds to the user's
> Python.
>
> [1]
> http://stackoverflow.com/questions/6019042/is-there-a-way-to-add-a-namespace-prefix-setuptools-package-distributions
>
> Mike
>
> On 10/10/2012 08:50 AM, Michael Droettboom wrote:
>
> This is related to using develop mode.  I never use that (I use virtualenvs
> instead), so this doesn't get much testing.  This seems to have broken when
> we started to ship separate versions of dateutil for python2 and python3.
> setuptools doesn't seem to like the fact that we rename dateutil_py2 to
> dateutil when installing (since in develop mode it doesn't really install or
> move anything).  That's problematic, of course.  I'll have to see if there's
> another way to handle this.
>
> Mike
>
> On 10/09/2012 09:36 PM, Gökhan Sever wrote:
>
> Hello,
>
> With a fresh
>
> git clone git://github.com/matplotlib/matplotlib.git
> sudo python setupegg.py develop
>
> Starting ipython --pylab I get this error:
>
> .../matplotlib/lib/matplotlib/dates.py in <module>()
>     120 import matplotlib.ticker as ticker
>     121
> --> 122 from dateutil.rrule import rrule, MO, TU, WE, TH, FR, SA, SU,
> YEARLY, \
>     123      MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY, SECONDLY
>     124 from dateutil.relativedelta import relativedelta
>
> ImportError: No module named dateutil.rrule
>
>
> Installing dateutil 1.5 fixes this.
>
> mpl install log shows the following:
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
>               dateutil: matplotlib will provide
>                   pytz: matplotlib will provide
>
> Will dateutil be shipped with mpl or this line needs to be updated?
>
> Thanks.
>
>
> --
> Gökhan

Gökhan, did you implement the symlink fix? If so, would you mind
making a pull request out of it? I was just about to look into doing
this, but if you've done it already that'd save us some effort rolling
out fixes for 1.2.

Cheers.
Damon

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [Matplotlib-users] data grid problem

[Damon M. <dam...@gm...>]

On Wed, Oct 10, 2012 at 3:55 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, Oct 10, 2012 at 9:40 AM, rand0m <ra...@0x...> wrote:
>>
>> Hello,
>>
>> I'm new to matplotlib and I hope you can help me out with my question.
>> When drawing for example a Rectangle() I have to specify it like the
>> following:
>> rect = Rectangle((1, 3), 2, 20, facecolor="#aaaaaa")
>>
>> Where 2 is the length and 20 is the height. (1,3) is for xy.
>>
>> Imagine a coordination system where x-axis should represent the value 0
>> to 100. I would like to draw the rectangle from 50 to 60 on x-axis.  So
>> I would specify:
>>
>> rect = Rectangle((50, 3), 10, 20, facecolor="#aaaaaa")
>>
>> But this does not work as desired because at the xtick 50 the x-axis
>> does not "hold" the value 50 but 5 because I made xticks 1-100 with step
>> 10. So my x-axis "holds" the values 1-10. But I need 1-100.
>>
>> If anyone knows what Im missing I d be glad to hear about it :-).
>>
>> thank you
>>
>
> I am not quite sure I understand what you mean.  Can you attach an image of
> the plot you made so far?
>
> Ben Root

I'm not sure if adding a patch autoscales the view, try

rect = Rectangle((50, 3), 10, 20, facecolor="#aaaaaa")
ax.add_patch(rect)
ax.set_xlim(0, 100)
ax.set_ylim(0, 25)

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [Matplotlib-users] Accessing WMS and ESRI REST services in Matplotlib

[klo uo <kl...@gm...>]

I guess that's it?

warpimage() as it is now, checks if passed image is url, so we can add
additional check if image is url, with urlparse to deduce image coordinates
and projection if present, then overlay it over already created Basemap
object.

Re: [Matplotlib-users] Accessing WMS and ESRI REST services in Matplotlib

[klo uo <kl...@gm...>]

On Thu, Oct 11, 2012 at 4:40 AM, klo uo wrote:

> Not sure, but as in example posted, 'img' is HTTPmessage pointing to
> server, and I can't see how we can deduce georeference as 'wms' object is
> named arbitrary, it could have been named to anything:
>

What am I talking about? We can deduce from 'img.url' itself:

========================================
In [23]: import urlparse
In [24]: urlparse.parse_qs(img.url)
Out[24]:
{'COLORSCALERANGE': ['271.2,308'],
 'CRS': ['EPSG:4326'],
 'STYLES': ['boxfill/rainbow'],
 'VERSION': ['1.3.0'],
 'bbox': ['-118,22,-108,32'],
 'bgcolor': ['0xFFFFFF'],
 'exceptions': ['application/vnd.ogc.se_xml'],
 'format': ['image/png'],
 'height': ['250'],
 '
http://motherlode.ucar.edu:8080/thredds/wms/fmrc/NCEP/NAM/CONUS_12km/NCEP-NAM-CONUS_12km-noaaport_best.ncd?layers':
['Temperature_height_above_ground'],
 'request': ['GetMap'],
 'srs': ['None'],
 'transparent': ['TRUE'],
 'version': ['1.1.1'],
 'width': ['250']}
========================================

So we have all information about the the service in a nice dictionary,
reading it's url