matplotlib-users Mailing List for matplotlib

On Thu, Apr 19, 2012 at 1:21 PM, Goyo <goy...@gm...> wrote:

> El día 19 de abril de 2012 05:31, questions anon
> <que...@gm...> escribió:
> > Thank you, I was able to get it to work but only if I imported datetime
> > within the loop, otherwise I ended up with the
> > AttributeError: type object 'datetime.datetime' has no attribute
> 'datetime'
> > and if I added 'import datetime' at the top of my script it had an error
> > where I loop through combining each month
> > "    stop_month = datetime(2011, 03, 01)
> > TypeError: 'module' object is not callable"
>
> If you can write a standalone, minimal executable script which
> reproduces the problem I'll take a look. Send it as an attachement and
> add sample data files if necessary.
>
> Goyo
>
>
The issue is that there is a slight mixup in namespaces.  There is a module
called datetime, and that module contains a class object called datetime.
So, if your imports at the top are "import datetime", then all your
module-related stuff need to be prepended with "datetime.". But, if your
imports at the top are "from datetime import datetime", then you can use
the object freely, but you can't use anything else from the module unless
you also import it.

Here is the tricky part.  In your code, you did the following:

from datetime import datetime

If you then did:

import datetime

depending on the order the two were, one would overwrite the other.  You
can only have one thing called "datetime".  Personally, I would do one of
two things:

import datetime as dt

and use "dt.datetime()" to create datetime objects as well as call
functions like "dt.strftime()". Or, do

from datetime import datetime, date, timedelta, strftime

and get replace calls like "datetime.datetime()" and "datetime.strftime()"
with just "datetime()" and "strftime()".

I hope that clears things up.  Namespaces are a honking good idea, but
having objects be the same exact name as a module gets confusing very
easily.

Cheers!
Ben Root

El día 19 de abril de 2012 05:31, questions anon
<que...@gm...> escribió:
> Thank you, I was able to get it to work but only if I imported datetime
> within the loop, otherwise I ended up with the
> AttributeError: type object 'datetime.datetime' has no attribute 'datetime'
> and if I added 'import datetime' at the top of my script it had an error
> where I loop through combining each month
> "    stop_month = datetime(2011, 03, 01)
> TypeError: 'module' object is not callable"

If you can write a standalone, minimal executable script which
reproduces the problem I'll take a look. Send it as an attachement and
add sample data files if necessary.

Goyo

I think I get what the problem really is. The mouse input is apparently 
asynchronous and re-entrant rather than queued. That is my mouse 
handlers are getting called while in progress (e.g. it continues to run 
continuously while "stopped" on a breakpoint inside a mouse handler). 
This causes all manner of mischief. So the issue is not about missing 
events, but rather that the order of events is being screwed up by 
re-entrancy.

Is this a property of tk (I'm familiar with many event-driven GUIs, but 
not very familiar with tk)?

I'm guessing that a good possible solution might be to queue the mouse 
events myself, and then handle them in the right order. Any other 
suggestions?

On 4/19/2012 7:43 AM, Ken Seehart wrote:
> Mouse input occasionally apparently loses mouse events. The effect is 
> a sometimes "sticky" quality to the mouse. I believe this is due to 
> incorrect handling of the mouse input queue in the main loop.
>
> Getting a mouse input queue right is a bit tricky in the presence of 
> latency since you can't be looking at the mouse state at every 
> nanosecond, and therefore inevitably miss some events. However, it 
> should be possible to guarantee the following absolutes with a correct 
> implementation, regardless of factors such as cpu load associated with 
> the handlers:
>
> 1. If the mouse is currently lingering at some location, the most 
> recent move event should be at this final position.
> 2. If the mouse button is currently lingering in an up state, there 
> must be a mouse up that is more recent than mouse down.
> 3. If the mouse button is currently lingering in a down state, there 
> must be a mouse down that is more recent than mouse up.
> 4. The mouse button state for any mouse event should be consistent 
> with the most recent mouse up/down event.
>
> Currently, none of the first three are guaranteed, but I'm not certain 
> about the fourth. I think this should be considered a high priority 
> defect because it impacts the feel of all matplotlib applications that 
> use the mouse (i.e. although it's not a show stopper for most apps, it 
> is important because it affects a very large number of apps).
>
> How to reproduce:
> Make an application with a dragable object, and add some heavy duty 
> computation in the mouse handlers to create extra latency.
> Item 1 can be demonstrated by moving the mouse rapidly back and forth 
> and then stopping. Occasionally the object will not be where the mouse 
> settles. Sometimes it appears that the mouse events are queued up in 
> the wrong order (i.e. the object jumps back to a previous mouse 
> position).
> Items 2 and 3 are very intermittent, but can be achieved by lots of 
> jerky motion while clicking. Sometimes the object will "stick" to the 
> mouse (i.e. the final mouse up was lost).
>
> Note that the issue is not simply the jumpy quality, as that is 
> obviously to be expected when the handler is slow. Rather the issue is 
> that the mouse state does not always "settle" into the correct final 
> state after motion. Be sure that you understand this point clearly 
> before responding.
>
> Fixing this would result is a much smoother mouse feel. :-)
>
> Does the Matplotlib project have a public bug tracking system 
> somewhere? I can't seem to find it.
>
>
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Mouse input occasionally apparently loses mouse events. The effect is a 
sometimes "sticky" quality to the mouse. I believe this is due to 
incorrect handling of the mouse input queue in the main loop.

Getting a mouse input queue right is a bit tricky in the presence of 
latency since you can't be looking at the mouse state at every 
nanosecond, and therefore inevitably miss some events. However, it 
should be possible to guarantee the following absolutes with a correct 
implementation, regardless of factors such as cpu load associated with 
the handlers:

1. If the mouse is currently lingering at some location, the most recent 
move event should be at this final position.
2. If the mouse button is currently lingering in an up state, there must 
be a mouse up that is more recent than mouse down.
3. If the mouse button is currently lingering in a down state, there 
must be a mouse down that is more recent than mouse up.
4. The mouse button state for any mouse event should be consistent with 
the most recent mouse up/down event.

Currently, none of the first three are guaranteed, but I'm not certain 
about the fourth. I think this should be considered a high priority 
defect because it impacts the feel of all matplotlib applications that 
use the mouse (i.e. although it's not a show stopper for most apps, it 
is important because it affects a very large number of apps).

How to reproduce:
Make an application with a dragable object, and add some heavy duty 
computation in the mouse handlers to create extra latency.
Item 1 can be demonstrated by moving the mouse rapidly back and forth 
and then stopping. Occasionally the object will not be where the mouse 
settles. Sometimes it appears that the mouse events are queued up in the 
wrong order (i.e. the object jumps back to a previous mouse position).
Items 2 and 3 are very intermittent, but can be achieved by lots of 
jerky motion while clicking. Sometimes the object will "stick" to the 
mouse (i.e. the final mouse up was lost).

Note that the issue is not simply the jumpy quality, as that is 
obviously to be expected when the handler is slow. Rather the issue is 
that the mouse state does not always "settle" into the correct final 
state after motion. Be sure that you understand this point clearly 
before responding.

Fixing this would result is a much smoother mouse feel. :-)

Does the Matplotlib project have a public bug tracking system somewhere? 
I can't seem to find it.

Hi,

I'm new to this mailing list, I'm writing here because I was not able to
solve searching in the web.
I would like to display subplot data divided per week, I write this code:

https://gist.github.com/2412755

But I have 2 problems that I would like to solve:

1) I would like to see the xticks label for the first plot too, at the
moment it is shown only for the second subplot.

2) I would like to move the xticks label of 0.5 of the  xticks width, at
the moment I have:

 # +-------+-------+-------+-------+-------+-------+--------+

# 04/02 04/03 04/04 04/02 04/03 04/04 04/04

# Mon Tue Wed Thu Fri Sat Sun


and I would like this:


# +-------+-------+-------+-------+-------+-------+--------+

# 04/02 04/03 04/04 04/02 04/03 04/04 04/04

# Mon Tue Wed Thu Fri Sat Sun

Any hints?

Pietro

Handling alpha can become very tricky with matplotlib.
The problem is not specific for legend thing, but how attribute of
patches are updated when the update_from method is called.
Here is an example.


  from matplotlib.patches import Patch

  pa1 = Patch(alpha=None, fc='none', ec='b')
  pb1 = Patch(alpha=1, fc='none', ec='b')

  pa2 = Patch()
  pb2 = Patch()

  pa2.update_from(pa1)
  pb2.update_from(pb1)

  assert pa1.get_fc() == pa2.get_fc()
  assert pb1.get_fc() == pb2.get_fc()

And the second assertion fails.
fc="none" sets facecolor to (0,0,0,0) but when update_from is called,
somehow its alpha value is overridden to 1 (because of alpha=1).
This seems to be a bug and maybe we need to tweak the update_from
method to get it right. But others may think differently. I'll file an
issue with it.

Meanwhile, please explicitly set fill=False to avoid filling. e.g.,

  ax.fill(y,x, label='alpha=1', alpha=0.5, fc='none', ec='r', fill=False)

Regards,

-JJ




On Tue, Apr 17, 2012 at 12:49 AM, Paul Hobson <pmh...@gm...> wrote:
> On Mon, Apr 16, 2012 at 4:58 AM, Yannick Copin
> <yan...@la...> wrote:
>> Hi List,
>>
>> I think I found a bug in legend of a fill command (see attached code and
>> figure) when the facecolor is 'none' but the alpha is not None (I'm using
>> latest matplotlib 1.1.0). If confirmed, should I fill in a but report?
>
> I see identical behavior in Christoph Gohlke's Windows build of
> Matplotlib 1.2.X for Python 3.2.
>
> The same thing occurs if you remove the "alpha=None" altogether.
> -paul
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Thank you, I was able to get it to work but only if I imported datetime
within the loop, otherwise I ended up with the
AttributeError: type object 'datetime.datetime' has no attribute 'datetime'
and if I added 'import datetime' at the top of my script it had an error
where I loop through combining each month
"    stop_month = datetime(2011, 03, 01)
TypeError: 'module' object is not callable"
It seems very messy with importing datetime everywhere but I am not sure
what the problem is. Below is the code I am using that works:


import numpy as np
import matplotlib.pyplot as plt
from numpy import ma as MA
from mpl_toolkits.basemap import Basemap
from datetime import datetime
import os
from StringIO import StringIO
from osgeo import gdal, gdalnumeric, ogr, osr
import glob
from datetime import date, timedelta
import matplotlib.dates as mdates
import time

rainmax=[]
rainmin=[]
rainmean=[]
yearmonthlist=[]
yearmonth_int=[]

OutputFolder=r"E:/test_out/"
GLOBTEMPLATE = r"e:/Rainfall/rainfall-{year}/r{year}{month:02}??.txt"

def accumulate_month(year, month):
    files = glob.glob(GLOBTEMPLATE.format(year=year, month=month))
    monthlyrain=[]
    for ifile in files:
        f=np.genfromtxt(ifile,skip_header=6)
        monthlyrain.append(f)

    import datetime
    yearmonth=datetime.datetime(year,month,1)
    yearmonthlist.append(yearmonth)
    yearmonthint=str(year)+str(month)
    from datetime import date, datetime
    d=datetime.strptime(yearmonthint, '%Y%m')
    date_string=d.strftime('%Y%m')
    yearmonthint=int(date_string)
    yearmonth_int.append(yearmonthint)
    r_max, r_mean, r_min=MA.max(monthlyrain), MA.mean(monthlyrain),
MA.min(monthlyrain)
    rainmax.append(r_max)
    rainmean.append(r_mean)
    rainmin.append(r_min)


###loop through months and years
stop_month = datetime(2011, 12, 31)
month = datetime(2011, 01, 01)
while month < stop_month:
    accumulate_month(month.year, month.month)
    month += timedelta(days=32)
    month = month.replace(day=01)


### Plot timeseries of max data
x=yearmonthlist
y=rainmax
x2=yearmonth_int

print x, y, x2

fig, ax=plt.subplots(1)

z=np.polyfit(x2,y,1)
p=np.poly1d(z)

plt.plot(x,y)
plt.plot(x,p(x2),'r--') #add trendline to plot
print "y=%.6fx+(%.6f)"%(z[0],z[1])

fig.autofmt_xdate()
ax.fmt_xdata=mdates.DateFormatter('%Y%m')
ax.xaxis.set_major_formatter(mdates.DateFormatter('%Y%m'))

plt.xlabel("year-month")
plt.ylabel("Precipitation (mm)")
plt.title("Max monthly precipition")
plt.savefig(OutputFolder+"MaxMonthlyPrecip.png")
plt.show()




On Thu, Apr 19, 2012 at 2:52 AM, Goyo <goy...@gm...> wrote:

> El día 18 de abril de 2012 07:59, questions anon
> <que...@gm...> escribió:
> > I am not exactly sure how to use datetime objects instead of strings.
> > This is the code I am working with at the moment and the code works
> except
> > for the dates, they are just weird numbers along the x-axis.
>
> Seems like you're plotting yearmonthlist in the x axis, which is a
> list of strings and each string is the concatenation of the string
> representations of two numbers. So numbers in the x axis are to be
> expected.
>
> You can create datetime objects this way:
>
> d = datetime.datetime(year, month, 1)
>
> Then create an array of datetime objects and use it as the x parameter to
> plot.
>
> Goyo
>