matplotlib-users Mailing List for matplotlib

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.
>

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

On Thu, Oct 11, 2012 at 3:31 AM, Jeff Whitaker wrote:
> But warpimage assumes the image is of global extent - perhaps we could
> make warpimage smart enough to get the georeferencing from the wms
> instance but that would require some work.  There must be some way to
> let the WMS server do the image warping and convert the result to
> something imshow can read - perhaps by writing to a png file (or
> CStringIO instance) and then reading it back in with imread?

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:

========================================
from owslib.wms import WebMapService
server = '
http://motherlode.ucar.edu:8080/thredds/wms/fmrc/NCEP/NAM/CONUS_12km/NCEP-NAM-CONUS_12km-noaaport_best.ncd
'
wms = WebMapService(server)
...
========================================

I don't know how to make WebMapService instance for Basemap class, so can't
even tell if that's good idea or not, but we can add optional parameter to
warpimage() function which could help georeferencing? boundingbox?
Also as I think you mentioned that warpimage() is kind of resource hog, so
we should find other way if possible?

Anyhow, here is function that can read chunked response, so tell what you
think:

========================================
def imshow_chunked(img):
    if img.headers['transfer-encoding'] == 'chunked':
        import cStringIO
        sio_img = cStringIO.StringIO()
        while True:
            chunk = img.read()
            if not chunk:
                break
            sio_img.write(chunk)
        sio_img.seek(0)
        wms_img = imread(sio_img)
        sio_img.close()
    else:
        wms_img = imread(img)
    img.close()
    return imshow(wms_img, origin='upper')
========================================

Where 'img' is as in my previous mail - img = wms.getmap(...)

On 10/10/12 7:16 PM, klo uo wrote:
> On Wed, Oct 10, 2012 at 11:28 PM, Jeff Whitaker wrote:
>> I wonder whether it would be better to use OWSlib (http://geopython.github.com/OWSLib/) for OGS/WMS support, instead of trying to roll our own solution.  It only has ElementTree as a dependency.  Klo - would you be interested in rewriting your wmsimage method using OWSlib?  I bet it would simplify the code quite a bit.
>
> Hi Jeff,
>
> that's good idea :D
> But really, OWSlib is very small package that doesn't depend on
> anything so why rewrite, right?
>
> I installed it and played with it shortly. It provides all sorts of
> useful functions for WMS service and it can return HTTPmessage
> suitable for writing to file object, but not for imshow()/imread() as
> it's chunked encoded, as I mentioned in that gist sample. So my
> suggestion is we just use warpimage() and handle WMS that way, as
> warpimage() uses temp file with urlretrieve(). Although we can use
> cStringIO and avoid temp file.
>
> So user handles WMS through OWSLib the way he likes and then passes it
> to warpimage() like this (taken from docs):
>
> ========================================
> m = Basemap(...)
> img = wms.getmap(layers=['global_mosaic'],
>                   styles=['visual_bright'],
>                   srs='EPSG:4326',
>                   bbox=(-112, 36, -106, 41),
>                   size=(300, 250),
>                   format='image/jpeg'
>                  )
>
> m.warpimage(image=img.url)
> ========================================
>
> where obviously wms in OWSLib WebMapService class instance
Klo:

But warpimage assumes the image is of global extent - perhaps we could 
make warpimage smart enough to get the georeferencing from the wms 
instance but that would require some work.  There must be some way to 
let the WMS server do the image warping and convert the result to 
something imshow can read - perhaps by writing to a png file (or 
CStringIO instance) and then reading it back in with imread?

-Jeff

On Wed, Oct 10, 2012 at 11:28 PM, Jeff Whitaker wrote:
>
> I wonder whether it would be better to use OWSlib (http://geopython.github.com/OWSLib/) for OGS/WMS support, instead of trying to roll our own solution.  It only has ElementTree as a dependency.  Klo - would you be interested in rewriting your wmsimage method using OWSlib?  I bet it would simplify the code quite a bit.


Hi Jeff,

that's good idea :D
But really, OWSlib is very small package that doesn't depend on
anything so why rewrite, right?

I installed it and played with it shortly. It provides all sorts of
useful functions for WMS service and it can return HTTPmessage
suitable for writing to file object, but not for imshow()/imread() as
it's chunked encoded, as I mentioned in that gist sample. So my
suggestion is we just use warpimage() and handle WMS that way, as
warpimage() uses temp file with urlretrieve(). Although we can use
cStringIO and avoid temp file.

So user handles WMS through OWSLib the way he likes and then passes it
to warpimage() like this (taken from docs):

========================================
m = Basemap(...)
img = wms.getmap(layers=['global_mosaic'],
                 styles=['visual_bright'],
                 srs='EPSG:4326',
                 bbox=(-112, 36, -106, 41),
                 size=(300, 250),
                 format='image/jpeg'
                )

m.warpimage(image=img.url)
========================================

where obviously wms in OWSLib WebMapService class instance

A bit of searching gave me this much simpler solution:

import matplotlib
import matplotlib.pyplot as plt
import numpy as np
import datetime
import matplotlib.dates as m_dates
import matplotlib.ticker as ticker

def make_month_axis(dates, y, ax, fig):

     newax = fig.add_axes(ax.get_position())
     newax.spines['bottom'].set_position(('outward', 25))
     newax.patch.set_visible(False)
     newax.yaxis.set_visible(False)
     newax.plot_date(dates, y, visible=False)

     newax.xaxis.set_major_locator(m_dates.MonthLocator())
newax.xaxis.set_minor_locator(m_dates.MonthLocator(bymonthday=15))

     newax.xaxis.set_major_formatter(ticker.NullFormatter())
     newax.xaxis.set_minor_formatter(m_dates.DateFormatter('%b'))

     for tick in newax.xaxis.get_minor_ticks():
         tick.tick1line.set_markersize(0)
         tick.tick2line.set_markersize(0)
         tick.label1.set_horizontalalignment('center')


start = datetime.datetime(2012, 8, 26)
dates = [start]
for i in range(1,10):
     dates.append(dates[-1] + datetime.timedelta(days=7))
y = np.random.normal(10, 5, len(dates))
fig = plt.figure()
fig.subplots_adjust(bottom=0.2, right=0.85, wspace=.8, hspace=.8)
ax = fig.add_subplot(1,1,1)
ax.plot(dates, y)
ax.xaxis.set_major_formatter( matplotlib.dates.DateFormatter('%W'))
make_month_axis(dates = dates, y = y, ax = ax, fig = fig)

plt.show()

Paul



On 10/8/12 11:03 PM, Paul Tremblay wrote:
> I often have to make graphs with time series, with each point being 
> the start of a week. Below is the result I wish:
>
> However, in order to make the secondary x axis the the month labels, I 
> need something like 40 lines of code. My strategy consists in first 
> drawing the rates in the normal way and using matplotlib's 
> dateFormatter to set the week numbers. That part is easy.
>
> In order to draw the x axis below to show when the weeks occur, I draw 
> two more lines, and makes these lines invisible. The first line has as 
> the x points the start of each month, and the y values as the 
> corresponding rate. The second line has as its x value the middle of 
> each month, with the corresponding y value.
>
> Below is my code. I have to use such a graph quite often--so often, in 
> fact, that if I don't find an easier way to make the secondary x axis, 
> I will store the code in my own library for re-use. Does anyone know 
> of a simpler, more elegant way?
>
> Thanks!
>
> Paul
>
> import matplotlib
> import matplotlib.pyplot as plt
> import numpy as np
> import matplotlib.dates
> from datetime import datetime
> from datetime import timedelta
>
>
> def unique_months(dates, rates):
>     """
>     returns two lists, one of the first time a month occurs, the 
> second, the
>     rates representing that month
>
>     """
>     y = [rates[0]]
>     temp = dates[0] - timedelta(days=dates[0].day)
>     months = [temp]
>     found = [dates[0].month]
>     counter = 0
>     for  d in dates:
>         month = d.month
>         if month not in found:
>             new_date = d - timedelta(days=d.day)
>             months.append(new_date)
>             y.append(rates[counter])
>             found.append(month)
>         counter += 1
>     return (months, y)
>
> def half_months(dates, defects):
>     """
>     returns two lists, one the middle of the month occurs, the second, the
>     rates representing that month
>
>     """
>     months, y = unique_months(dates, defects)
>     new_months =[]
>     new_y = []
>     counter = 0
>     for m in months:
>         new_date = m - timedelta(days=m.day) + timedelta(days=15)
>         if new_date <= months[-1]:
>             new_months.append(new_date)
>             new_y.append(y[counter])
>         counter += 1
>     return new_months, new_y
>
> dates = [datetime(2012,8,19), datetime(2012,8,26),datetime(2012, 9, 
> 3), datetime(2012,9,10), datetime(2012,9,17), datetime(2012,9,24),
>         datetime(2012,10,1), datetime(2012,10,8)]
> rates = [2,3,4,2,5,3,7,2]
> fig = plt.figure()
> fig.set_size_inches(3,3)
> x1, y1 = unique_months(dates, rates)
> ax = fig.add_subplot(1,1,1)
> ax.yaxis.grid(True, linestyle='-', which='major', color='lightgrey', 
> alpha=0.5)
> ax.set_axisbelow(True)
> fig.subplots_adjust(bottom=0.2, right=0.85, wspace=.8, hspace=.8)
> # plot dates and rates
> ax.plot(dates, rates)
> ax.xaxis.set_major_formatter(matplotlib.dates.DateFormatter('%W'))
>
> # start with bottom axis
>
> x2, y2 = half_months(dates, rates)
>
> # add tick marks for start of month
> # x1 starts at first of each mont; y1 doesn't matter
> newax = fig.add_axes(ax.get_position())
> newax.spines['bottom'].set_position(('outward', 25))
> newax.patch.set_visible(False)
> newax.yaxis.set_visible(False)
> newax.plot_date(x1, y1,  visible=False)
> newax.xaxis.set_major_locator( matplotlib.dates.MonthLocator())
> newax.set_xticklabels([])
>
> # set labels for months, inbetween tick marsk
> # x2 is 15th of each month
> axmlab = fig.add_axes(ax.get_position())
> axmlab.spines['bottom'].set_position(('outward', 25))
> axmlab.patch.set_visible(False)
> axmlab.yaxis.set_visible(False)
> axmlab.plot_date(x2, y2,  visible=False)
> axmlab.xaxis.set_major_formatter( matplotlib.dates.DateFormatter('%b'))
> axmlab.xaxis.set_major_locator(matplotlib.dates.DayLocator(bymonthday=1))
> # get rid of tick marks for this axis
> for i, line in enumerate(axmlab.get_xticklines() + 
> newax.get_yticklines()):
>     line.set_visible(False)
> axmlab.plot_date(x2, y2,  visible=False)
> axmlab.xaxis.set_major_locator( matplotlib.dates.MonthLocator())
>
> plt.xlabel('Week in Year')
> ax.set_ylabel('Rates')
> plt.savefig('temp.png', dpi=100)
>
>