matplotlib-devel Mailing List for matplotlib (Page 3)

Given that we have been able to turn on registration only very late, the
EuroScipy conference committee is extending the deadline for abstract
submission for the 2010 EuroScipy conference.
On Thursday May 20th, at midnight Samoa time, we will turn off the
abstract submission on the conference site. Up to then, you can modify
the already-submitted abstract, or submit new abstracts.
We are very much looking forward to your submissions to the conference.
Gaël Varoquaux
Nicolas Chauvat
-- 
 
EuroScipy 2010 is the annual European conference for scientists using
Python. It will be held July 8-11 2010, in ENS, Paris, France.
 
Links: 
Conference website: http://www.euroscipy.org/conference/euroscipy2010
Call for papers: http://www.euroscipy.org/card/euroscipy2010_call_for_papers
Practical information: http://www.euroscipy.org/card/euroscipy2010_practical_information
 

Given that we have been able to turn on registration only very late, the
EuroScipy conference committee is extending the deadline for abstract
submission for the 2010 EuroScipy conference.
On Thursday May 20th, at midnight Samoa time, we will turn off the
abstract submission on the conference site. Up to then, you can modify
the already-submitted abstract, or submit new abstracts.
We are very much looking forward to your submissions to the conference.
GaVaroquaux
Nicolas Chauvat
-- 
 
EuroScipy 2010 is the annual conference for scientists using Python. It
will be held July 8-11 2010, in ENS, Paris, France.
 
Links: 
Conference website: http://www.euroscipy.org/conference/euroscipy2010
Call for papers: http://www.euroscipy.org/card/euroscipy2010_call_for_papers
Practical information: http://www.euroscipy.org/card/euroscipy2010_practical_information
 

We have an app that creates some background threads and is doing work at 
the same time it displays a pylab figure. We noticed the worker threads 
stopped working while we're looking at the figure and then things start 
working again after we close it.
Turns out, from the faq [1], you can have background threads with GtkAgg 
if you call gobject.threads_init().
I changed my matplotlib/backends/backend_gtk.py to:
try:
 import gobject
 import gtk; gdk = gtk.gdk
 import pango
 gobject.threads_init()
except ImportError:
 raise ImportError("Gtk* backend requires pygtk to be installed.")
Sure enough, I can now have my worker threads continue in the background 
while we're watching the figure. I'm not sure if this should be the 
default behavior or if there ought to be a way to customize the backend 
for individual usage.
A side note however: We run the same app with a wxPython frontend 
sometimes. In this mode, the backend is WxAgg. The Wx backend does not 
have the same default behavior as the GTK backend. Our worker threads 
continue to do work properly with this backend. I tried PyQt with a 
small test app as well. It appears only GTK blocked everything so I 
think perhaps this change should be applied.
-Dennis
[1] http://bit.ly/buQROp

On Fri, May 14, 2010 at 2:39 PM, Tony S Yu <to...@mi...> wrote:
> I'm running the Qt4 backend, and I noticed that I'd frequently get error messages saying I was pressing unrecognized keys. It turns out that the direction keys aren't recognized in the qt4 backend. (I'm using direction keys to switch between spaces in OSX, so this error gets triggered quite frequently)
>
> One possible fix is to just add the direction keys to the list of valid keys (see patch below). Alternatively, the key event code could just ignore unrecognized keys (i.e. `key == None`). This change could be made in FigureCanvasQT.keyPressEvent (in backends.backend_qt4.py) or, more generally, in FigureCanvasBase.key_press_event (in backend_bases.py).
>
> -Tony
>
> %---Diff
>
> Index: lib/matplotlib/backends/backend_qt4.py
> ===================================================================
> --- lib/matplotlib/backends/backend_qt4.py   (revision 8315)
> +++ lib/matplotlib/backends/backend_qt4.py   (working copy)
> @@ -129,6 +129,10 @@
>   keyvald = { QtCore.Qt.Key_Control : 'control',
>         QtCore.Qt.Key_Shift : 'shift',
>         QtCore.Qt.Key_Alt : 'alt',
> +        QtCore.Qt.Key_Up : 'up',
> +        QtCore.Qt.Key_Right : 'right',
> +        QtCore.Qt.Key_Down : 'down',
> +        QtCore.Qt.Key_Left : 'left',
>        }
>   # left 1, middle 2, right 3
>   buttond = {1:1, 2:3, 4:2}
>
>
> %---Full traceback
>
> Traceback (most recent call last):
> File "/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_qt4.py", line 198, in keyPressEvent
>  FigureCanvasBase.key_press_event( self, key )
> File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line 1459, in key_press_event
>  self.callbacks.process(s, event)
> File "/Users/Tony/python/devel/mpl/lib/matplotlib/cbook.py", line 169, in process
>  func(*args, **kwargs)
> File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line 2079, in key_press
>  if event.key in fullscreen_keys:
> TypeError: 'in <string>' requires string as left operand, not NoneType
I can commit the change to backend_qt4, but I need to run the change
to backendbases by the other devs. Is there any reason not to do the
following?:
===================================================================
--- lib/matplotlib/backend_bases.py	(revision 8306)
+++ lib/matplotlib/backend_bases.py	(working copy)
@@ -1,4 +1,3 @@
-
 """
 Abstract base classes define the primitives that renderers and
 graphics contexts must implement to serve as a matplotlib backend
@@ -1450,9 +1449,11 @@
 def key_press_event(self, key, guiEvent=None):
 """
- This method will be call all functions connected to the
+ This method will call all functions connected to the
 'key_press_event' with a :class:`KeyEvent`
 """
+ if key is None:
+ return
 self._key = key
 s = 'key_press_event'
 event = KeyEvent(s, self, key, self._lastx, self._lasty,
guiEvent=guiEvent)

I'm running the Qt4 backend, and I noticed that I'd frequently get error messages saying I was pressing unrecognized keys. It turns out that the direction keys aren't recognized in the qt4 backend. (I'm using direction keys to switch between spaces in OSX, so this error gets triggered quite frequently)
One possible fix is to just add the direction keys to the list of valid keys (see patch below). Alternatively, the key event code could just ignore unrecognized keys (i.e. `key == None`). This change could be made in FigureCanvasQT.keyPressEvent (in backends.backend_qt4.py) or, more generally, in FigureCanvasBase.key_press_event (in backend_bases.py).
-Tony
%---Diff
Index: lib/matplotlib/backends/backend_qt4.py
===================================================================
--- lib/matplotlib/backends/backend_qt4.py	(revision 8315)
+++ lib/matplotlib/backends/backend_qt4.py	(working copy)
@@ -129,6 +129,10 @@
 keyvald = { QtCore.Qt.Key_Control : 'control',
 QtCore.Qt.Key_Shift : 'shift',
 QtCore.Qt.Key_Alt : 'alt',
+ QtCore.Qt.Key_Up : 'up',
+ QtCore.Qt.Key_Right : 'right',
+ QtCore.Qt.Key_Down : 'down',
+ QtCore.Qt.Key_Left : 'left',
 }
 # left 1, middle 2, right 3
 buttond = {1:1, 2:3, 4:2}
%---Full traceback
Traceback (most recent call last):
 File "/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_qt4.py", line 198, in keyPressEvent
 FigureCanvasBase.key_press_event( self, key )
 File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line 1459, in key_press_event
 self.callbacks.process(s, event)
 File "/Users/Tony/python/devel/mpl/lib/matplotlib/cbook.py", line 169, in process
 func(*args, **kwargs)
 File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line 2079, in key_press
 if event.key in fullscreen_keys:
TypeError: 'in <string>' requires string as left operand, not NoneType

I was using matplotlib 0.99.1.1. I just set up an Ubuntu system in
VirtualBox so I could run the current svn trunk, and all is well. It
looks like the fix has already been implemented.
On Wed, May 12, 2010 at 3:06 PM, Jeff Klukas <kl...@wi...> wrote:
> I've looked now through the source code for axes.hist, and I see where
> the problem is. If any value of any bin of the histogram is zero,
> then axes.fill fails, as zero is necessarily outside the y boundaries
> of the axes for log scale.
>
> Already, a default value of 1e-100 is chosen for the first and last
> points given to axes.fill. If you also clean the histogram, replacing
> all zero y-values with 1e-100, then the fill succeeds. I see no
> downside to this treatment, since the default value has already been
> introduced.
>
> The user will still need to choose a reasonable lower limit for the y-axis.
>
> Any objections or concerns?
>
> Cheers,
> Jeff
>
> On Wed, May 12, 2010 at 11:13 AM, Jeff Klukas <kl...@wi...> wrote:
>> When creating a histogram with histtype='stepfilled' and log=True, the
>> fill always ends up getting cut off diagonally. It looks like it's
>> connection one datapoint with 10^-100 on the other side of the plot.
>> So, also, it looks like it's always choosing 10^-100 as an arbitrary
>> lower limit, which is another problem.
>>
>> Is this a known bug? Does anybody have ideas for an intelligent way
>> to handle stepfilled log histograms?
>>
>> A working example is below, with the output plot attached.
>>
>> Thanks,
>> Jeff
>>
>> || Jeff Klukas, Research Assistant, Physics
>> || University of Wisconsin -- Madison
>> || jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
>> || http://www.hep.wisc.edu/~jklukas/
>>
>> ---------------------------------------------
>> #!/usr/bin/env python
>> import numpy as np
>> import matplotlib.mlab as mlab
>> import matplotlib.pyplot as plt
>>
>> mu, sigma = 100, 15
>> x = mu + sigma*np.random.randn(10000)
>>
>> # the histogram of the data
>> n, bins, patches = plt.hist(x, 50, normed=1, facecolor='green', alpha=0.75,
>>              log=True, histtype='stepfilled')
>>
>> plt.xlabel('Smarts')
>> plt.ylabel('Probability')
>> plt.title(r'$\mathrm{Histogram\ of\ IQ:}\ \mu=100,\ \sigma=15$')
>> plt.axis([40, 160, 0, 0.03])
>> plt.grid(True)
>>
>> plt.show()
>> ---------------------------------------------
>>
>

 Registration for EuroScipy
 <http://www.euroscipy.org//conference/euroscipy2010> is finally open
To register, go to the website 
<http://www.euroscipy.org//conference/euroscipy2010>, create an account, 
and you will see a /‘register to the conference’/ button on the left. 
Follow it to a page which presents a /’shoping cart’/. Simply submitting 
this information registers you to the conference, and on the left of the 
website, the button will now display /‘You are registered for the 
conference’/.
The registration fee is 50 euros for the conference, and 50 euros for 
the tutorial. Right now there is no payment system: you will be 
contacted later (in a week) with instructions for paying.
We apologize for such a late set up. We do realize this has come as an 
inconvenience to people.
*Do not wait to register: the number of people we can host is limited.*
 An exciting program
 Tutorials: from beginners to experts
We have two tutorial tracks:
 * *Introductory tutorial* <http://www.euroscipy.org/track/871>: to
 get you to speed on scientific programming with Python.
 * *Advanced tutorial* <http://www.euroscipy.org/track/872>: experts
 sharing their knowledge on specific techniques and libraries.
 We are very fortunate to have a top notch set of presenters.
 Scientific track: doing new science in Python
Although the abstract submission is not yet over, We can say that we are 
going to have a rich set of talks, looking at the current submissions. 
In addition to the contributed talks, we have:
 * *Keynote speakers*
 <http://www.euroscipy.org/conference/euroscipy2010>: Hans Petter
 Langtangen and Konrard Hinsen, two major player of scientific
 computing in Python.
 * *Lightning talks* <http://www.euroscipy.org/talk/937>: one hour
 will be open for people to come up and present in a flash an
 interesting project.
 Publishing papers
We are talking with the editors of a major scientific computing journal, 
and the odds are quite high that we will be able to publish a special 
issue on scientific computing in Python based on the proceedings of the 
conference. The papers will undergo peer-review independently from the 
conference, to ensure high quality of the final publication.
 Call for papers
Abstract submission is still open, though not for long. We are 
soliciting contributions on scientific libraries and tools developed 
with Python and on scientific or engineering achievements using Python. 
These include applications, teaching, future development directions, and 
current research. See the call for papers 
<http://www.euroscipy.org/card/euroscipy2010_call_for_papers>.
*We are very much looking forward to passionate discussions about Python 
in science in Paris*
*Nicolas Chauvat and Gaël Varoquaux*

The registration for
EuroScipy<http://www.euroscipy.org//conference/euroscipy2010>is
finally open.
To register, go to the
website<http://www.euroscipy.org//conference/euroscipy2010>,
create an account, and you will see a *‘register to the conference’* button
on the left. Follow it to a page which presents a *’shoping cart’*. Simply
submitting this information registers you to the conference, and on the left
of the website, the button will now display *‘You are registered for the
conference’*.
The registration fee is 50 euros for the conference, and 50 euros for the
tutorial. Right now there is no payment system: you will be contacted later
(in a week) with instructions for paying.
We apologize for such a late set up. We do realize this has come as an
inconvenience to people.
*Do not wait to register: the number of people we can host is limited.*
An exciting program Tutorials: from beginners to experts
We have two tutorial tracks:
 - *Introductory tutorial* <http://www.euroscipy.org/track/871>: to get
 you to speed on scientific programming with Python.
 - *Advanced tutorial* <http://www.euroscipy.org/track/872>: experts
 sharing their knowledge on specific techniques and libraries.
 We are very fortunate to have a top notch set of presenters.
Scientific track: doing new science in Python
Although the abstract submission is not yet over, We can say that we are
going to have a rich set of talks, looking at the current submissions. In
addition to the contributed talks, we have:
 - *Keynote speakers* <http://www.euroscipy.org/conference/euroscipy2010>:
 Hans Petter Langtangen and Konrard Hinsen, two major player of scientific
 computing in Python.
 - *Lightning talks* <http://www.euroscipy.org/talk/937>: one hour will be
 open for people to come up and present in a flash an interesting project.
Publishing papers
We are talking with the editors of a major scientific computing journal, and
the odds are quite high that we will be able to publish a special issue on
scientific computing in Python based on the proceedings of the conference.
The papers will undergo peer-review independently from the conference, to
ensure high quality of the final publication.
Call for papers
Abstract submission is still open, though not for long. We are soliciting
contributions on scientific libraries and tools developed with Python and on
scientific or engineering achievements using Python. These include
applications, teaching, future development directions, and current research.
See the call for
papers<http://www.euroscipy.org/card/euroscipy2010_call_for_papers>
.
*We are very much looking forward to passionate discussions about Python in
science in Paris*
*Nicolas Chauvat and Gaël Varoquaux*

Patch committed as svn revision 8316.
Ian

patch attached
qt4ed_demo.py is an example file which should be put in
matplotlib\examples\pylab_examples
other than that figureoptions.py is the only file changed.
On Wed, May 12, 2010 at 11:56 PM, Darren Dale <dsd...@gm...> wrote:
> No, I'm sorry. Its unfair to you that I am the bottleneck here. I just
> looked for the patch at
> http://sourceforge.net/tracker/?func=detail&aid=2981606&group_id=80706&atid=560722
> but didn't find it. Is the figureoptions.py file there all that is
> needed?
>
> On Wed, May 12, 2010 at 4:46 PM, Peter Butterworth <bu...@gm...> wrote:
>> Hi Darren,
>>
>> Any progress on looking at the Qt4editor patch ?
>>
>>
>> On Wed, Apr 14, 2010 at 1:44 PM, Darren Dale <dsd...@gm...> wrote:
>>>> Darren might be helpful at this point to submit the changes.
>>>
>>> My time is completely spoken for this week. But I'll have a look this
>>> weekend if some helpful person doesn't beat me to it.
>>>
>>> Darren
>>
>>
>> --
>> thanks,
>> peter butterworth
>>

No, I'm sorry. Its unfair to you that I am the bottleneck here. I just
looked for the patch at
http://sourceforge.net/tracker/?func=detail&aid=2981606&group_id=80706&atid=560722
but didn't find it. Is the figureoptions.py file there all that is
needed?
On Wed, May 12, 2010 at 4:46 PM, Peter Butterworth <bu...@gm...> wrote:
> Hi Darren,
>
> Any progress on looking at the Qt4editor patch ?
>
>
> On Wed, Apr 14, 2010 at 1:44 PM, Darren Dale <dsd...@gm...> wrote:
>>> Darren might be helpful at this point to submit the changes.
>>
>> My time is completely spoken for this week. But I'll have a look this
>> weekend if some helpful person doesn't beat me to it.
>>
>> Darren
>
>
> --
> thanks,
> peter butterworth
>

Hi Darren,
Any progress on looking at the Qt4editor patch ?
On Wed, Apr 14, 2010 at 1:44 PM, Darren Dale <dsd...@gm...> wrote:
>> Darren might be helpful at this point to submit the changes.
>
> My time is completely spoken for this week. But I'll have a look this
> weekend if some helpful person doesn't beat me to it.
>
> Darren
-- 
thanks,
peter butterworth

I've looked now through the source code for axes.hist, and I see where
the problem is. If any value of any bin of the histogram is zero,
then axes.fill fails, as zero is necessarily outside the y boundaries
of the axes for log scale.
Already, a default value of 1e-100 is chosen for the first and last
points given to axes.fill. If you also clean the histogram, replacing
all zero y-values with 1e-100, then the fill succeeds. I see no
downside to this treatment, since the default value has already been
introduced.
The user will still need to choose a reasonable lower limit for the y-axis.
Any objections or concerns?
Cheers,
Jeff
On Wed, May 12, 2010 at 11:13 AM, Jeff Klukas <kl...@wi...> wrote:
> When creating a histogram with histtype='stepfilled' and log=True, the
> fill always ends up getting cut off diagonally. It looks like it's
> connection one datapoint with 10^-100 on the other side of the plot.
> So, also, it looks like it's always choosing 10^-100 as an arbitrary
> lower limit, which is another problem.
>
> Is this a known bug? Does anybody have ideas for an intelligent way
> to handle stepfilled log histograms?
>
> A working example is below, with the output plot attached.
>
> Thanks,
> Jeff
>
> || Jeff Klukas, Research Assistant, Physics
> || University of Wisconsin -- Madison
> || jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
> || http://www.hep.wisc.edu/~jklukas/
>
> ---------------------------------------------
> #!/usr/bin/env python
> import numpy as np
> import matplotlib.mlab as mlab
> import matplotlib.pyplot as plt
>
> mu, sigma = 100, 15
> x = mu + sigma*np.random.randn(10000)
>
> # the histogram of the data
> n, bins, patches = plt.hist(x, 50, normed=1, facecolor='green', alpha=0.75,
>              log=True, histtype='stepfilled')
>
> plt.xlabel('Smarts')
> plt.ylabel('Probability')
> plt.title(r'$\mathrm{Histogram\ of\ IQ:}\ \mu=100,\ \sigma=15$')
> plt.axis([40, 160, 0, 0.03])
> plt.grid(True)
>
> plt.show()
> ---------------------------------------------
>

On 05/11/2010 10:18 PM, Ian Thomas wrote:
> On 11 May, Eric Firing wrote:
>> I am somewhat inclined to simply commit it, or to give you commit
>> rights, in view not only of the triangular grid work but of the great
>> work you did in fixing problems with cntr.c. Do you have a sourceforge
>> login?
>
> I've created a sourceforge login with the username ianthomas23, and
> I'm happy to commit my patch if you are happy for me to do so.
>
Absolutely, and thanks to Mike for going ahead and giving you the access.
> I can confirm that I am prepared to maintain my code in mpl, as John
> Hunter asked me a while ago.
Thank you!
Eric

When creating a histogram with histtype='stepfilled' and log=True, the
fill always ends up getting cut off diagonally. It looks like it's
connection one datapoint with 10^-100 on the other side of the plot.
So, also, it looks like it's always choosing 10^-100 as an arbitrary
lower limit, which is another problem.
Is this a known bug? Does anybody have ideas for an intelligent way
to handle stepfilled log histograms?
A working example is below, with the output plot attached.
Thanks,
Jeff
|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
|| http://www.hep.wisc.edu/~jklukas/
---------------------------------------------
#!/usr/bin/env python
import numpy as np
import matplotlib.mlab as mlab
import matplotlib.pyplot as plt
mu, sigma = 100, 15
x = mu + sigma*np.random.randn(10000)
# the histogram of the data
n, bins, patches = plt.hist(x, 50, normed=1, facecolor='green', alpha=0.75,
 log=True, histtype='stepfilled')
plt.xlabel('Smarts')
plt.ylabel('Probability')
plt.title(r'$\mathrm{Histogram\ of\ IQ:}\ \mu=100,\ \sigma=15$')
plt.axis([40, 160, 0, 0.03])
plt.grid(True)
plt.show()
---------------------------------------------

Ian,
I've added you as a developer, and you should now have SVN write 
access. (This may require explicitly setting a username in SVN the 
first time you commit.)
Mike
Ian Thomas wrote:
> On 11 May, Eric Firing wrote:
> 
>> I am somewhat inclined to simply commit it, or to give you commit
>> rights, in view not only of the triangular grid work but of the great
>> work you did in fixing problems with cntr.c. Do you have a sourceforge
>> login?
>> 
>
> I've created a sourceforge login with the username ianthomas23, and
> I'm happy to commit my patch if you are happy for me to do so.
>
> I can confirm that I am prepared to maintain my code in mpl, as John
> Hunter asked me a while ago.
>
> Ian
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On 11 May, Eric Firing wrote:
> I am somewhat inclined to simply commit it, or to give you commit
> rights, in view not only of the triangular grid work but of the great
> work you did in fixing problems with cntr.c. Do you have a sourceforge
> login?
I've created a sourceforge login with the username ianthomas23, and
I'm happy to commit my patch if you are happy for me to do so.
I can confirm that I am prepared to maintain my code in mpl, as John
Hunter asked me a while ago.
Ian

Ian Thomas wrote:
> On 15 April, Ian Thomas wrote:
>> I've attached the patch for the new triangular grid functionality.
> 
> As nobody has commented on the patch I submitted to add triangular
> grid functions, I can only assume that nobody has looked at it.
I have NO time to look at it, but I think it's great think to add.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On 05/10/2010 10:09 PM, Ian Thomas wrote:
> On 15 April, Ian Thomas wrote:
>> I've attached the patch for the new triangular grid functionality.
>
> As nobody has commented on the patch I submitted to add triangular
> grid functions, I can only assume that nobody has looked at it. This
> is a final friendly reminder that some people considered that it would
> be useful and I'd rather not throw away useful work.
>
Ian,
I'm sorry, this has been on my mind, but I have put it off day by day. 
In addition, I'm not a C++ writer.
I am somewhat inclined to simply commit it, or to give you commit 
rights, in view not only of the triangular grid work but of the great 
work you did in fixing problems with cntr.c. Do you have a sourceforge 
login?
Eric
> Ian
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 15 April, Ian Thomas wrote:
> I've attached the patch for the new triangular grid functionality.
As nobody has commented on the patch I submitted to add triangular
grid functions, I can only assume that nobody has looked at it. This
is a final friendly reminder that some people considered that it would
be useful and I'd rather not throw away useful work.
Ian

No worries. I meant no offense by the word "hack": sometimes the 
simplest approach is the best, and obviously it worked just fine for a 
long time. It seems newer versions of pdflatex are starting to care 
about the dpi metadata...
Mike
Gary Ruben wrote:
> Just saw this thread and thought I should explain that this was indeed a 
> hack by me which was aimed to do exactly what Michael said. I never 
> thought there'd be any side effects from doing this - it's interesting 
> that pdfLaTeX balks because it has never done so for me. Anyway, thanks 
> Michael for addressing this.
>
> Gary R.
>
> Michael Droettboom wrote:
> 
>> Ok, I have a better fix in SVN r8300. imsave now accepts a "dpi" kwarg 
>> (default of 100) to set the DPI metadata in the file.
>>
>> Mike
>>
>> Michael Droettboom wrote:
>> 
>>> You're right. Thanks for the sanity check.
>>>
>>> What's happening is that when using imsave is used, it generates a 
>>> figure image with a dpi of 1 (to force 1 output pixel per input pixel), 
>>> but this is sort of a hack. Let me see if I can find a way around this 
>>> hack.
>>>
>>> Mike
>>> 
> <snip>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hello matplotlib people,
I have run into a problem with the default behaviour for formatting the
axis numbers. For some reason they were not being rounded correctly for
me, for example the number on the axis would be of the form 1.6000001
while the offset was 1e-7 + 4.76928. I am not sure why this is, but it
seemed I needed to use the FormatSrtFormatter to fix the numbers in the
axis.
The problem I had was that I needed the offset displayed and unlike the
ScalarFormatter, FormatSrtFormatter does not have an option to specify
this. I made a new version of the FormatSrtFormatter by overriding the
call method from ScalarFormatter ..
from matplotlib.ticker import ScalarFormatter
class FormatStrFormatter(ScalarFormatter):
 """
 Use a format string (fmt) to format the tick label, other options
are the same as for ScalarFormatter
 """
 
 def __init__(self, useOffset=True, useMathText=True, fmt='%1.3f'):
 self.fmt = fmt
 ScalarFormatter.__init__(self, useOffset, useMathText)
 def __call__(self, x, pos=None):
 'Return the format for tick val *x* at position *pos*' 
 return self.fmt % ( (x-self.offset)*pow(10,
(-1*self.orderOfMagnitude) ) )
Not sure if this is the best way to do it but it seemed to solve the
problem for me.
Regards,
--
Richard Graham

Hi,
I spend some time this week for polishing matplotlib2tikz
<http://github.com/nicki/matplotlib2tikz>, and for the test cases that
I rolled out now, it converts simple matplotlib plots, i.e., colored
line plots, legends, labels, color bars,... pretty much all right, so
I think it'd be useful to get a bit more exposure here.
Is it possible to have it pointed to from somewhere on the matplotlib page?
Cheers,
Nico

Just saw this thread and thought I should explain that this was indeed a 
hack by me which was aimed to do exactly what Michael said. I never 
thought there'd be any side effects from doing this - it's interesting 
that pdfLaTeX balks because it has never done so for me. Anyway, thanks 
Michael for addressing this.
Gary R.
Michael Droettboom wrote:
> Ok, I have a better fix in SVN r8300. imsave now accepts a "dpi" kwarg 
> (default of 100) to set the DPI metadata in the file.
> 
> Mike
> 
> Michael Droettboom wrote:
>> You're right. Thanks for the sanity check.
>>
>> What's happening is that when using imsave is used, it generates a 
>> figure image with a dpi of 1 (to force 1 output pixel per input pixel), 
>> but this is sort of a hack. Let me see if I can find a way around this 
>> hack.
>>
>> Mike
<snip>

Hi All,
We are planning to publish a new book on Matplotlib 0.99.1. I am looking for
potential authors to write this book, who are an expert.
Title: Matplotlib 0.99.1 Plotting Cookbook
Planned to be a 300 pages book, targeted at Python developers who are
familiar with Matplotlib,to teach them advanced recipes.
To give you an idea about the way things work at Packt:
 *The editorial team at Packt works with the author through the project.
 *We pay a royalty of 16% and an advance against it.
 *The marketing team at Packt ensures that the book is well promoted.
 *In its ongoing commitment to OpenSource, Packt donates a percentage of
revenue generated by the book to the OpenSource project on which it is
based. We have donated more than 100 000 dollars since inception in 2004.
Could you please let me know if you find it interesting to author this book?
Mail me at sne...@pa....
Thanks,
-- 
Snehman Kohli
Author Relationship Executive
Packt Publishing
www.PacktPub.com
Email: sne...@pa...
MSN: sne...@pa...
Interested in becoming an author? Visit http://authors.packtpub.com for all
the information you need about writing for Packt.
-- 
View this message in context: http://old.nabble.com/Author-Matplotlib-0.99.1---Packt-Publishing-tp28444404p28444404.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.