matplotlib-devel Mailing List for matplotlib (Page 2)

Hi,
2009年11月18日 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
> In gnuplot, I can do the following:
>
> set format x "%.0s %cHz"
>
> ...and this will set the x-axis labels (on a semilogx style plot) to
> be "10 Hz", "100 Hz", "1 kHz", "10 kHz", etc.
I ended up implementing this myself, it wasn't too hard. I've attached
the code if anyone else is interested. I don't know matplotlib that
well, so I don't know if there's much duplication of code in there.
I thought I'd CC the dev list in case others think it might be useful.
If not, sorry for the noise.
Cheers,
Jason

Michael Droettboom wrote:
> I know it's been a while since you announced this, but I'm just looking 
> into this now. 
Also, I got some ways in making the buildbot build with numscons, but I 
stopped at a bug where it looked like the matplotlib.tests.* modules 
were not getting installed:
http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64%2C%20scons/builds/13/steps/test/logs/stdio
I haven't had a chance to debug this further, but I'm open to ideas. 
Also, this branch is building from a git repository (a mirror of David's 
which I can't clone normally, for some reason), for what it's worth.
> David Cournapeau wrote:
> 
>> Hi,
>>
>> I don't know if that's of any interest for matplotlib developers,
>> but I added scripts to build matplotlib with numscons:
>>
>> http://github.com/cournape/matplotlib/tree/scons_build
>>
>> Not every configuration is supported yet, but I can successfully build
>> matplotlib on Linux with gtk or wx backends. It only adds 3 files + one
>> configuration example, and does not touch any other file.
>>
>> The advantage of numscons over distutils is automatic dependency
>> handling (no need to rm -rf build to get accurate build), easy compiler
>> flags customization, parallel build, etc... There are some instructions
>> in setupscons.py.
>>
>> It is still experimental (I have not implemented check for QT, as well
>> as windows, macosx and qt backends), but it seems to work well. I will
>> add mac os x and windows backends soon (I started this to debug issues
>> on 64 bits version of matplotlib),
>>
>> cheers,
>>
>> David
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay 
>> ahead of the curve. Join us from November 9-12, 2009. Register now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>> 
>
> 

I know it's been a while since you announced this, but I'm just looking 
into this now. My primary interest is having a build script that 
selects the correct c++ compiler and get around a long-standing 
distutils bug.
I'm running into a little speed bump here. It's failing on the 
pkg-config detection of gtk. I have user-locally built and installed 
packages for gtk (and many other things), so I set my PKG_CONFIG_PATH to 
a custom location. However, it appears that scons isn't passing this 
along to 'pkg-config'. By poking into scons.Action._subproc, it looks 
like it is only passing a limited set of environment variables ("PATH", 
"LD_LIBRARY_PATH" and "HOME") to the pkg-config subprocess. Is there an 
scons way to get it to use this environment variable?
Mike
 > python setupscons.py build
running build
running config_cc
unifing config_cc, config, build_clib, build_ext, build commands 
--compiler options
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands 
--fcompiler options
running build_src
build_src
building extension "matplotlib" sources
build_src: building npy-pkg config files
running build_py
running build_ext
customize UnixCCompiler
customize UnixCCompiler using build_ext
running scons
customize UnixCCompiler
Found executable /usr/bin/gcc
customize GnuFCompiler
Found executable /usr/bin/g77
gnu: no Fortran 90 compiler found
gnu: no Fortran 90 compiler found
customize GnuFCompiler
gnu: no Fortran 90 compiler found
gnu: no Fortran 90 compiler found
Found executable /usr/bin/g77
customize UnixCCompiler
customize UnixCCompiler using scons
Found executable /usr/bin/g++
Executing scons command (pkg is matplotlib): /home/mdroe/usr/bin/python 
"/home/mdroe/usr/lib/python2.5/site-packages/numscons/scons-local/scons.py" 
-f SConstruct -I. scons_tool_path="" src_dir="" 
pkg_path="lib/matplotlib" pkg_name="matplotlib" log_level=50 
distutils_libdir="../../../build/lib.linux-i686-2.5" 
distutils_clibdir="../../../build/temp.linux-i686-2.5" 
distutils_install_prefix="/home/mdroe/usr/lib/python2.5/site-packages/matplotlib" 
cc_opt=gcc cc_opt_path="/usr/bin" debug=0 f77_opt=g77 
f77_opt_path="/usr/bin" cxx_opt=g++ cxx_opt_path="/usr/bin" 
include_bootstrap=/home/mdroe/usr/lib/python2.5/site-packages/numpy/core/include 
bypass=0 import_env=0 silent=0 bootstrapping=0
scons: Reading SConscript files ...
Mkdir("build/scons/matplotlib")
Checking for freetype2 ... Yes
Checking for png ... Yes
Package pygtk-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `pygtk-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pygtk-2.0' found
OSError: 'pkg-config pygtk-2.0 gtk+-2.0 --cflags' exited 1:
 File "/wonkabar/data1/builds/matplotlib_scons/SConstruct", line 2:
 GetInitEnvironment(ARGUMENTS).DistutilsSConscript('SConscript')
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/numscons/core/numpyenv.py", 
line 135:
 build_dir = '$build_dir', src_dir = '$src_dir')
 File 
"/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/Script/SConscript.py", 
line 553:
 return apply(_SConscript, [self.fs,] + files, subst_kw)
 File 
"/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/Script/SConscript.py", 
line 262:
 exec _file_ in call_stack[-1].globals
 File 
"/wonkabar/data1/builds/matplotlib_scons/build/scons/matplotlib/SConscript", 
line 271:
 if not config.CheckPyGTK():
 File 
"/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/SConf.py", 
line 650:
 ret = apply(self.test, (context,) + args, kw)
 File 
"/wonkabar/data1/builds/matplotlib_scons/build/scons/matplotlib/SConscript", 
line 132:
 pkg_config_cmd, autoadd=autoadd)
 File 
"/wonkabar/data1/builds/matplotlib_scons/build/scons/matplotlib/SConscript", 
line 249:
 return check_from_pkg_config(context, cmd_base, src, autoadd=autoadd)
 File 
"/wonkabar/data1/builds/matplotlib_scons/build/scons/matplotlib/SConscript", 
line 61:
 compile_info = context.env.ParseFlags([' '.join(cflags_cmd)])
 File 
"/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/Environment.py", 
line 791:
 do_parse(arg, do_parse)
 File 
"/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/Environment.py", 
line 672:
 for t in arg: me(t, me)
 File 
"/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/Environment.py", 
line 677:
 arg = self.backtick(arg[1:])
 File 
"/wonkabar/data1/usr/lib/python2.5/site-packages/numscons/scons-local/scons-local-1.2.0/SCons/Environment.py", 
line 593:
 raise OSError("'%s' exited %d" % (command, status))
Checking for pygtk >= (2, 2, 0) ... error: Error while executing scons 
command. See above for more information.
If you think it is a problem in numscons, you can also try executing the 
scons
command with --log-level option for more detailed output of what numscons is
doing, for example --log-level=0; the lowest the level is, the more detailed
the output it.
David Cournapeau wrote:
> Hi,
>
> I don't know if that's of any interest for matplotlib developers,
> but I added scripts to build matplotlib with numscons:
>
> http://github.com/cournape/matplotlib/tree/scons_build
>
> Not every configuration is supported yet, but I can successfully build
> matplotlib on Linux with gtk or wx backends. It only adds 3 files + one
> configuration example, and does not touch any other file.
>
> The advantage of numscons over distutils is automatic dependency
> handling (no need to rm -rf build to get accurate build), easy compiler
> flags customization, parallel build, etc... There are some instructions
> in setupscons.py.
>
> It is still experimental (I have not implemented check for QT, as well
> as windows, macosx and qt backends), but it seems to work well. I will
> add mac os x and windows backends soon (I started this to debug issues
> on 64 bits version of matplotlib),
>
> cheers,
>
> David
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> 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

The matplotlib 0.99.1 installer for Python 2.6 for Windows 64-bit that 
is currently on SourceForge (matplotlib-0.99.1.win-amd64-py2.6.exe) will 
not work with the upcoming numpy 1.4.0 release. The installer was built 
against an ABI incompatible version of numpy 1.4.svn.
Is there going to be a matplotlib 0.99.2 or 1.0 release soon, or could 
matplotlib-0.99.1.win-amd64-py2.6.exe be replaced with a new build?
Christoph

Hi all,
I'm pleased to announce that the book about Matplotlib has been
published. More info at:
 http://sandrotosi.blogspot.com/2009/11/matplotlib-for-python-developers.html
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On 19-Nov-09, at 5:36 PM, Scot Denhalter wrote:
> On Thu, Nov 19, 2009 at 2:46 PM, Eric Firing <ef...@ha...> 
> wrote:
>>
>> You don't need a fortran compiler for numpy, even if you are building
>> from source; and you probably don't need to build from source. Did 
>> you
>> try the suggested binary packages for the Mac as listed on the nltk 
>> site?
>>
>> http://www.nltk.org/download
> Yes, I downloaded the files recommended on that webpage. The tar.gz 
> files
> unpack, but they do not install, and I am too much of a newbie to 
> figure out
> how to install the files in the unpacked folder. No matter where I 
> placed
> the numpy folder, I couldn't get Python 2.6 to find and install numpy.
>
> Nevertheless, I did finally find .dmg downloads for numpy and 
> matplotlib and
> they installed without my having to get involved.
>
> But when I run a dispersion_plot function, I get an error message from
> Python, which I don't understand:
>
> Warning (from warnings module):
> File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ 
> site-packages/matplotlib/dates.py",
> line 91
> import pytz.zoneinfo
> ImportWarning: Not importing directory
> '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ 
> site-packages/pytz/zoneinfo':
> missing __init__.py
>
> Python launches the dispersion plot in another window as it apparently
> should, so why am I getting an error message? Perhaps, those of you 
> who
> program in Python can explain this to me.
I don't know why it would be trying to import zoneinfo since it 
doesn't seem to be a code directory, it just contains various data for 
timezone stuff. I'm CC'ing matplotlib-devel since that's really a 
matplotlib problem and not a Python or NumPy one.
David
P.S. please don't top-post replies, it makes things hard to follow.

Yes, for efficiency reasons matplotlib will use a reference to original 
data whenever possible, rather than copying it. Also, when using the 
pylab/pyplot API, matplotlib figures also stay around until they are 
explicitly deleted. You may need an explicit call to "clf('all')" to 
remove the figures, and thus references to the memmap'd file.
However, my advice would be to just not use memmap. I can't imagine 
matplotlib performs very well if the data can't all fit in memory, so 
you might as well just load it all into memory anyway.
Mike
Mathew Yeates wrote:
> There is definitely something wrong with matplotlib/numpy. Consider 
> the following
> >from numpy import *
> >mydata=memmap('map.dat',dtype=float64,mode='w+',shape=56566500)
> > del mydata
>
> I can now remove the file map.dat with (from the command line) $rm map.dat
>
> However
> If I plot mydata before the line
> > del mydata
>
>
> I can't get rid of the file until I exit python!!
> Does matplotlib keep a reference to the data? How can I remove this 
> reference?
>
> Mathew
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

There is definitely something wrong with matplotlib/numpy. Consider the
following
>from numpy import *
>mydata=memmap('map.dat',dtype=float64,mode='w+',shape=56566500)
> del mydata
I can now remove the file map.dat with (from the command line) $rm map.dat
However
If I plot mydata before the line
> del mydata
I can't get rid of the file until I exit python!!
Does matplotlib keep a reference to the data? How can I remove this
reference?
Mathew

On Thu, Nov 19, 2009 at 6:02 AM, Ensitof <ens...@gm...> wrote:
>
> I got the same problem and posted my question in this forum
> http://www.developpez.net/forums/d836964/autres-langages/python-zope/calcul-scientifique/matplotlib-scatter3d-colorisation-fonction-z/
> (here) a few days ago... My question receives a lot of visits but no
> reaction however I think it may be an important information for people
> wanting to use matplotlib efficiently. Please let me know if you can find
> anything about it :confused: Even if everything works perfect with 2D
> scatter I can't solve this issue with scatter3D. Knowing that's it's a bug
> should already be a nice answer...
>
Please file a bug on the tracker and I will assign it to Reinier
http://sourceforge.net/tracker/?atid=560720&group_id=80706&func=browse
Thanks,
JDH

I got the same problem and posted my question in this forum 
http://www.developpez.net/forums/d836964/autres-langages/python-zope/calcul-scientifique/matplotlib-scatter3d-colorisation-fonction-z/
(here) a few days ago... My question receives a lot of visits but no
reaction however I think it may be an important information for people
wanting to use matplotlib efficiently. Please let me know if you can find
anything about it :confused: Even if everything works perfect with 2D
scatter I can't solve this issue with scatter3D. Knowing that's it's a bug
should already be a nice answer...
Luc Estebanez wrote:
> 
> Dear All,
> 
> I am trying to use the new 3D facilities offered by Matplotlib.
> I know the mlab module of Mayavi, but I am interested in the vector 
> export facilities offered by matplotlib.
> 
> Here is my issue : I can't manage to vary the color and/or size of the 
> markers when doing 3D scatter plots :
> 
> fig = plt.figure()
> ax = Axes3D(fig)
> ax.scatter([1,2,3],[3,1,2],[1,2,0],c='r',s=[4,10,20])
> 
> The code above doesn't show size changes for each marker, just like :
> 
> ax.scatter([1,2,3],[3,1,2],[1,2,0])
> 
> Does anyone have an idea of what is going on ?
> 
> Thanks a lot,
> luc
> 
> (I already posted this issue on the user list, but it seems to be a bug, 
> and no one their seemed very interested in this issue either...)
> 
> 
> 
> ---------------
> luc Estebanez
> Graduate Student,
> ENS, Paris
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day 
> trial. Simplify your report design, integration and deployment - and focus
> on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
-- 
View this message in context: http://old.nabble.com/3D-Axes-scatter-%3A-no-possibility-to-vary-color-size-of-markers-tp26335289p26421301.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hi
I have a line of matplotlib code
-self.ax.plot(plot_data,mif)
that causes the line
-self.data=numpy.zeros(shape=dims) #dims is a constant, not large
to throw a MemoryError exception.
(if I comment out the first line I get no error.)
Is it possible that matplotlib is dereferencing an array somewhere?
This is on a windows xp machine with latest numpy and the latest matplotlib.
I have a feeling this may be a nightmare to figure out what matplotlib
and/or numpy are doing wrong. Any ideas where I can start?
Mathew

Eric Firing wrote:
> Drain, Theodore R (343P) wrote:
> 
>> FYI: Thanks for the help John.
>> 
>> This is case where having path.simplify = True causes the plot to be 
>> incorrect. Attached are two different images (not quite the same data 
>> as the original post- but the same affect). One with path.simplify as 
>> true and one as false. Notice the bottom right plot - the simplify case 
>> causes a massive change in the way the plot looks. 
>> 
>> It looks like we'll be reconfiguring things for our users to make sure 
>> this is set to false for now. I haven't experimented w/ the threshold 
>> argument to see where this kicks in. It's definitely a function of plot 
>> size (which is probably expected after reading the simplify documentation).
>> 
>> Does anyone know if there is a good write up anywhere on the cases where 
>> having path.simplify=True is important? I'll search back through the 
>> old list posts and see what I can find...
>> 
>
> It is a matter of speed, and I think of some hard limits in agg on the 
> number of points it can handle.
> 
Exactly. To that, I would add that it greatly decreases file size for 
the vector formats (Ps, Pdf, Svg etc.), and also works around similar 
limitations in Adobe Acrobat Reader (and probably other renderers).
I consider any case where path.simplify *must* be False in order to get 
correct results to be a bug. The particular bug here (exercised in the 
attachment in James' original e-mail) was fixed relatively recently on 
October 21 (r7896). I can confirm the broken behavior with the most 
recently released version (0.99.1.2), but not with the 0.99.x 
maintenance branch in SVN. So this fix will make it into the next 
0.99.x point release.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Drain, Theodore R (343P) wrote:
> FYI: Thanks for the help John.
> 
> This is case where having path.simplify = True causes the plot to be 
> incorrect. Attached are two different images (not quite the same data 
> as the original post- but the same affect). One with path.simplify as 
> true and one as false. Notice the bottom right plot - the simplify case 
> causes a massive change in the way the plot looks. 
> 
> It looks like we'll be reconfiguring things for our users to make sure 
> this is set to false for now. I haven't experimented w/ the threshold 
> argument to see where this kicks in. It's definitely a function of plot 
> size (which is probably expected after reading the simplify documentation).
> 
> Does anyone know if there is a good write up anywhere on the cases where 
> having path.simplify=True is important? I'll search back through the 
> old list posts and see what I can find...
It is a matter of speed, and I think of some hard limits in agg on the 
number of points it can handle.
So far, every time someone has pointed out a problem--a case in which 
the simplification code makes a perceptible difference in the appearance 
of the plot--Mike D. has found a way to fix it.
I haven't followed this thread closely, but have you verified the 
problem with recent mpl, and have you provided a minimal script to 
trigger it?
Eric

FYI: Thanks for the help John.
This is case where having path.simplify = True causes the plot to be incorrect. Attached are two different images (not quite the same data as the original post- but the same affect). One with path.simplify as true and one as false. Notice the bottom right plot - the simplify case causes a massive change in the way the plot looks.
It looks like we'll be reconfiguring things for our users to make sure this is set to false for now. I haven't experimented w/ the threshold argument to see where this kicks in. It's definitely a function of plot size (which is probably expected after reading the simplify documentation).
Does anyone know if there is a good write up anywhere on the cases where having path.simplify=True is important? I'll search back through the old list posts and see what I can find...
Ted
________________________________
From: James Evans [jre...@ea...]
Sent: Friday, November 13, 2009 11:15 AM
To: 'matplotlib development list'
Subject: [matplotlib-devel] Dissapearing data?
All,
I have noticed a bizarre occurrence. I have a fairly dense plot that when viewed in a large figure I can see all of the data, but as I resize the plot smaller I start to see some of the data disappear. I understand that there is a pixel-space issue, but to someone who might not realize that their plot is physically too small, they might think that what they see is really true. In the attached example script (with data) you can see this behavior. When the plot gets small enough you never see anything reach the y value of 20.0. I found this to be a little disconcerting and was wondering if I can get a detailed explanation as to what I am seeing.
Thanks,
--James Evans

You are right Francisco. I was misinterpreting, and probably not having an
"x" is not an issue.
On Tue, Nov 17, 2009 at 1:25 PM, Francisco de la Peña <
del...@lp...> wrote:
> Hi Gökhan,
>
> I think that we are understanding differently the notation (what would mean
> that it is indeed confusing). For me 1e-10+3.207e-5 means: "to get your
> value read the figure from the axis, multiply it by 1e-10 and add 3.207e-5".
> The source of the confusion could be a missing "x" in front of 1e-10.
> Anyway the patch that I have submitted is not related to this problem, it
> only affects the way the offset is calculated, not the way it is displayed.
> I just tested an unmodified version of matplotlib and the "x" is not
> displayed there neither. The difference that the patch makes is that instead
> of 4x1e-8+2.995e-5 you get 99x1e-8+2.9e-5 that I think it is easier to
> read. In addition, if the number of significant figures in the axis range
> changes it takes it into account so the offset becomes human friendly for
> all the axis values.
>
> Cheers,
>
> Francisco
>
> 2009年11月17日 Gökhan Sever <gok...@gm...>
>
>
>>
>> On Tue, Nov 17, 2009 at 4:29 AM, Francisco de la Peña <
>> del...@lp...> wrote:
>>
>>> Hi Gökhan,
>>>
>>> I tried your example and I couldn't find anything wrong with the offset
>>> there. However, I agree that this particular mixture of scientific notation
>>> and offset looks confusing. Maybe in that case it will be better to write:
>>> x1e-10+320700e-10 . Is it what you mean?
>>>
>>
>> I think this could be better presented collecting the base terms under the
>> same exponent (i.e 320701e-10 and further 32e-6) Doesn't this look simpler?
>>
>>
>>
>>>
>>> Cheers,
>>>
>>> Francisco
>>>
>>> El 17 de noviembre de 2009 00:58, Gökhan Sever <gok...@gm...>escribió:
>>>
>>>>
>>>>
>>>> 2009年11月15日 Francisco Javier de la Peña <del...@lp...>
>>>>
>>>> Hi,
>>>>>
>>>>> I find it difficult to read the values of an axis when the offset is
>>>>> active. The problem is that many time I find myself doing calculations like
>>>>> -1.2345e2-0.048 to find out the value of the tick. I send enclosed a patch
>>>>> and a test file to, in my opinion, improve the readability of the ticks with
>>>>> an offset.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Francisco
>>>>>
>>>>
>>>> Hi Francisco,
>>>>
>>>> Could you try this simple case ?
>>>>
>>>> I[6]: a = np.linspace(0.00002, 0.00005, num=9348)
>>>>
>>>> I[7]: plot(a)
>>>>
>>>> Still ticks produce mingled values. Like 1e-10+3.207e-5 after some
>>>> zooming in.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>>>> 30-Day
>>>>> trial. Simplify your report design, integration and deployment - and
>>>>> focus on
>>>>> what you do best, core application coding. Discover what's new with
>>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Gökhan
>>>>
>>>>
>>>> --
>>>> This message has been scanned for viruses and
>>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
>>>> is
>>>> believed to be clean.
>>>>
>>>
>>>
>>
>>
>> --
>> Gökhan
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
>>
>> believed to be clean.
>>
>
>
-- 
Gökhan

Hi Gökhan,
I think that we are understanding differently the notation (what would mean
that it is indeed confusing). For me 1e-10+3.207e-5 means: "to get your
value read the figure from the axis, multiply it by 1e-10 and add 3.207e-5".
The source of the confusion could be a missing "x" in front of 1e-10.
Anyway the patch that I have submitted is not related to this problem, it
only affects the way the offset is calculated, not the way it is displayed.
I just tested an unmodified version of matplotlib and the "x" is not
displayed there neither. The difference that the patch makes is that instead
of 4x1e-8+2.995e-5 you get 99x1e-8+2.9e-5 that I think it is easier to
read. In addition, if the number of significant figures in the axis range
changes it takes it into account so the offset becomes human friendly for
all the axis values.
Cheers,
Francisco
2009年11月17日 Gökhan Sever <gok...@gm...>
>
>
> On Tue, Nov 17, 2009 at 4:29 AM, Francisco de la Peña <
> del...@lp...> wrote:
>
>> Hi Gökhan,
>>
>> I tried your example and I couldn't find anything wrong with the offset
>> there. However, I agree that this particular mixture of scientific notation
>> and offset looks confusing. Maybe in that case it will be better to write:
>> x1e-10+320700e-10 . Is it what you mean?
>>
>
> I think this could be better presented collecting the base terms under the
> same exponent (i.e 320701e-10 and further 32e-6) Doesn't this look simpler?
>
>
>
>>
>> Cheers,
>>
>> Francisco
>>
>> El 17 de noviembre de 2009 00:58, Gökhan Sever <gok...@gm...>escribió:
>>
>>>
>>>
>>> 2009年11月15日 Francisco Javier de la Peña <del...@lp...>
>>>
>>> Hi,
>>>>
>>>> I find it difficult to read the values of an axis when the offset is
>>>> active. The problem is that many time I find myself doing calculations like
>>>> -1.2345e2-0.048 to find out the value of the tick. I send enclosed a patch
>>>> and a test file to, in my opinion, improve the readability of the ticks with
>>>> an offset.
>>>>
>>>> Cheers,
>>>>
>>>> Francisco
>>>>
>>>
>>> Hi Francisco,
>>>
>>> Could you try this simple case ?
>>>
>>> I[6]: a = np.linspace(0.00002, 0.00005, num=9348)
>>>
>>> I[7]: plot(a)
>>>
>>> Still ticks produce mingled values. Like 1e-10+3.207e-5 after some
>>> zooming in.
>>>
>>>
>>>
>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>>> 30-Day
>>>> trial. Simplify your report design, integration and deployment - and
>>>> focus on
>>>> what you do best, core application coding. Discover what's new with
>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>>
>>>
>>>
>>> --
>>> Gökhan
>>>
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
>>> is
>>> believed to be clean.
>>>
>>
>>
>
>
> --
> Gökhan
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

On Tue, Nov 17, 2009 at 4:29 AM, Francisco de la Peña <
del...@lp...> wrote:
> Hi Gökhan,
>
> I tried your example and I couldn't find anything wrong with the offset
> there. However, I agree that this particular mixture of scientific notation
> and offset looks confusing. Maybe in that case it will be better to write:
> x1e-10+320700e-10 . Is it what you mean?
>
I think this could be better presented collecting the base terms under the
same exponent (i.e 320701e-10 and further 32e-6) Doesn't this look simpler?
>
> Cheers,
>
> Francisco
>
> El 17 de noviembre de 2009 00:58, Gökhan Sever <gok...@gm...>escribió:
>
>>
>>
>> 2009年11月15日 Francisco Javier de la Peña <del...@lp...>
>>
>> Hi,
>>>
>>> I find it difficult to read the values of an axis when the offset is
>>> active. The problem is that many time I find myself doing calculations like
>>> -1.2345e2-0.048 to find out the value of the tick. I send enclosed a patch
>>> and a test file to, in my opinion, improve the readability of the ticks with
>>> an offset.
>>>
>>> Cheers,
>>>
>>> Francisco
>>>
>>
>> Hi Francisco,
>>
>> Could you try this simple case ?
>>
>> I[6]: a = np.linspace(0.00002, 0.00005, num=9348)
>>
>> I[7]: plot(a)
>>
>> Still ticks produce mingled values. Like 1e-10+3.207e-5 after some zooming
>> in.
>>
>>
>>
>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>
>>
>> --
>> Gökhan
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
>>
>> believed to be clean.
>>
>
>
-- 
Gökhan

Hi Gökhan,
I tried your example and I couldn't find anything wrong with the offset
there. However, I agree that this particular mixture of scientific notation
and offset looks confusing. Maybe in that case it will be better to write:
x1e-10+320700e-10 . Is it what you mean?
Cheers,
Francisco
El 17 de noviembre de 2009 00:58, Gökhan Sever <gok...@gm...>escribió:
>
>
> 2009年11月15日 Francisco Javier de la Peña <del...@lp...>
>
> Hi,
>>
>> I find it difficult to read the values of an axis when the offset is
>> active. The problem is that many time I find myself doing calculations like
>> -1.2345e2-0.048 to find out the value of the tick. I send enclosed a patch
>> and a test file to, in my opinion, improve the readability of the ticks with
>> an offset.
>>
>> Cheers,
>>
>> Francisco
>>
>
> Hi Francisco,
>
> Could you try this simple case ?
>
> I[6]: a = np.linspace(0.00002, 0.00005, num=9348)
>
> I[7]: plot(a)
>
> Still ticks produce mingled values. Like 1e-10+3.207e-5 after some zooming
> in.
>
>
>
>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>
> --
> Gökhan
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

2009年11月15日 Francisco Javier de la Peña <del...@lp...>
> Hi,
>
> I find it difficult to read the values of an axis when the offset is
> active. The problem is that many time I find myself doing calculations like
> -1.2345e2-0.048 to find out the value of the tick. I send enclosed a patch
> and a test file to, in my opinion, improve the readability of the ticks with
> an offset.
>
> Cheers,
>
> Francisco
>
Hi Francisco,
Could you try this simple case ?
I[6]: a = np.linspace(0.00002, 0.00005, num=9348)
I[7]: plot(a)
Still ticks produce mingled values. Like 1e-10+3.207e-5 after some zooming
in.
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
Gökhan

Hi,
I find it difficult to read the values of an axis when the offset is active.
The problem is that many time I find myself doing calculations like
-1.2345e2-0.048 to find out the value of the tick. I send enclosed a patch
and a test file to, in my opinion, improve the readability of the ticks with
an offset.
Cheers,
Francisco

James Conners wrote:
> Hi,
>
> I did a quick search of the archives and didn't find anything so 
> here's a post of what I'm pretty sure is a bug in griddata of 
> matplotlib.mlab:
> Matplotlib version: 0.99.1.1
>
>
> mlab.py: Line 2527
>
> if hasattr(z,'mask'):
> x = x.compress(z.mask == False)
> y = y.compress(z.mask == False)
> z = z.compressed()
>
>
> This throws up if you have a scalar mask of 'False', which would 
> happen for instance after numpy.ma.masked_equal() where no values were 
> masked.
>
> A simple fix would be:
>
> if (hasattr(z, 'mask)):
> if (hasattr(z.mask, 'ndim')):
> x = x.compress(z.mask == False)
> y = y.compress(z.mask == False)
> z = z.compressed() 
>
> Not sure what the best numpy array attribute would be to check for.
>
> Thanks,
> James
>
James: It's fixed now in SVN, thanks for the report.
-Jeff

Hi,
I did a quick search of the archives and didn't find anything so here's a
post of what I'm pretty sure is a bug in griddata of matplotlib.mlab:
Matplotlib version: 0.99.1.1
mlab.py: Line 2527
if hasattr(z,'mask'):
 x = x.compress(z.mask == False)
 y = y.compress(z.mask == False)
 z = z.compressed()
This throws up if you have a scalar mask of 'False', which would happen for
instance after numpy.ma.masked_equal() where no values were masked.
A simple fix would be:
if (hasattr(z, 'mask)):
 if (hasattr(z.mask, 'ndim')):
 x = x.compress(z.mask == False)
 y = y.compress(z.mask == False)
 z = z.compressed()
Not sure what the best numpy array attribute would be to check for.
Thanks,
James

No, unfortunately I have not had time to review the patch. It is on my list.
On Mon, Nov 9, 2009 at 3:47 PM, Gökhan Sever <gok...@gm...> wrote:
> Darren,
>
> Have you happened to review Pierre's patch for the toolbar
> improvement? I am interested to see this integrated in mpl soon.
>
> Thanks.
>
> On Mon, Nov 9, 2009 at 2:43 PM, Pierre Raybaut <co...@py...> wrote:
>> Hi,
>>
>> I've already sent everything to Darren. I don't have any news but I
>> guess that it will be integrated soon.
>>
>> Pierre
>>
>> 2009年11月9日 Gökhan Sever <gok...@gm...>:
>>> Hi Pierre,
>>>
>>> What is the latest status on this improvement? Will you give a patch
>>> to the matplotlib?
>>>
>>> Please let me know.
>>>
>>> Thanks
>>>
>>> On Sat, Jun 6, 2009 at 9:49 AM, Pierre Raybaut <co...@py...> wrote:
>>>> 2009年4月28日 Dave Peterson <dpe...@en...>:
>>>>> Darren Dale wrote:
>>>>>
>>>>> On Tue, Apr 28, 2009 at 12:19 PM, Pierre Raybaut <co...@py...>
>>>>> wrote:
>>>>>>
>>>>>> 2009年4月28日 John Hunter <jd...@gm...>:
>>>>>> >
>>>>>> >
>>>>>> > On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut <co...@py...>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> Hi all,
>>>>>> >>
>>>>>> >> I would like to contribute to matplotlib with this enhancement for the
>>>>>> >> PyQt4 backend: the idea is to add a toolbar button to configure figure
>>>>>> >> options (axes, curves, ...).
>>>>>> >>
>>>>>> >> It's based on a tiny module called formlayout to generate PyQt4 form
>>>>>> >> dialog automatically.
>>>>>> >>
>>>>>> >> Some screenshots:
>>>>>> >> http://code.google.com/p/formlayout/
>>>>>> >>
>>>>>> >> So, if you're interested (all the following is GPL2):
>>>>>> >>
>>>>>> >> *matplotlib patch*
>>>>>> >>
>>>>>> >> In FigureManagerQT.__init__, added:
>>>>>> >> self.canvas.axes = self.canvas.figure.add_subplot(111)
>>>>>> >>
>>>>>> >> In NavigationToolbar2QT._init_toolbar, added:
>>>>>> >> a = self.addAction(self._icon("customize.png"), 'Customize',
>>>>>> >> self.edit_parameters)
>>>>>> >> a.setToolTip('Edit curves line and axes parameters')
>>>>>> >>
>>>>>> >> Added the following method in NavigationToolbar2QT:
>>>>>> >> def edit_parameters(self):
>>>>>> >>  from figureoptions import figure_edit
>>>>>> >>  figure_edit(self.canvas, self)
>>>>>> >>
>>>>>> >> *additionnal modules and data*
>>>>>> >>
>>>>>> >> formlayout.py (http://code.google.com/p/formlayout/)
>>>>>> >> figureoptions.py (http://code.google.com/p/PyQtShell/)
>>>>>> >> customize.png (http://code.google.com/p/PyQtShell/)
>>>>>> >
>>>>>> > Hi Pierre -- this looks very nice (the last link is broken though , I
>>>>>> > get a
>>>>>> > 404 error). We would be happy to include this in matplotlib or as a
>>>>>>
>>>>>> Here is the last link:
>>>>>> http://code.google.com/p/pyqtshell/
>>>>>>
>>>>>> > toolkit. To contribute it to to mpl, the license needs to be
>>>>>> > matplotlib
>>>>>> > compatible
>>>>>> > (http://matplotlib.sourceforge.net/devel/coding_guide.html#licenses) but
>>>>>> > we
>>>>>> > have more licensing flexibility in a toolkit, though we prefer to keep
>>>>>> > everything BSD compatible where possible.  And of course you would need
>>>>>> > to
>>>>>> > agree to maintain it :-) but I think many users would appreciate a GUI
>>>>>> > plot
>>>>>> > configuration dialog.
>>>>>>
>>>>>> I was not aware of this license restriction in matplotlib... I fully
>>>>>> understand the motivation, of course, but still: I wrote all this on
>>>>>> my free time which means no PyQt4 commercial license, so it can't be
>>>>>> anything but GPL. Sorry...
>>>>>
>>>>> I think you have overlooked a subtlety of PyQt4's license. The author of
>>>>> PyQt4 wrote on the enthought-dev mailing list:
>>>>>
>>>>> "PyQt is GPL but has exceptions that allow it to be used with BSD code -
>>>>> hence it's Ok for TraitsBackendQt to be BSD.
>>>>>
>>>>> However, the exception imposes additional conditions which, to all intents
>>>>> and purposes, infects the code with the GPL. To be fair to people that
>>>>> should be made clear in any text.
>>>>>
>>>>> It's still a good idea for TraitsBackendQt to use a BSD license because it
>>>>> allows commercial (ie. non-GPL) users to use it without problems."
>>>>>
>>>>> Darren
>>>>>
>>>>> I think it might be worth contacting the PyQt folks (Phil Thompson) about
>>>>> this. I think there might be some differences here because Phil was the
>>>>> author of TraitsBackendQt and thus his efforts didn't quite fall under the
>>>>> "develop under a free license, your results needs to be GPL" clause Qt/PyQt
>>>>> have in their licensing.
>>>>>
>>>>> -- Dave
>>>>>
>>>>>
>>>>
>>>> Hi all,
>>>>
>>>> Dave, you are absolutely right.
>>>>
>>>> Last week-end, I found myself surfing on PyQt's website and I told to
>>>> myself: what about re-reading the license? (always a pleasure) And
>>>> surprisingly, I found out that anyone using the GPL version of PyQt
>>>> can release source code under a very permissive license (like MIT or
>>>> BSD) thanks to the PyQt-GPL Exception, as long as PyQt itself is not
>>>> part of the distributed package (otherwise the whole package has to be
>>>> licensed under GPL) - and with other little restrictions. It was a
>>>> surprise because I've read here and there a lot of things on PyQt
>>>> license and the general idea was "if you write PyQt code without the
>>>> commercial license, your code *must* be licensed under GPL" - I can
>>>> tell now that it's not true (to be absolutely certain about it, I even
>>>> asked to Phil Thompson to confirm this, and he did).
>>>>
>>>> So, I switched all the code I was referring to in my original e-mail
>>>> to MIT license.
>>>> I guess now it could be integrated to matplotlib Qt4 backend?
>>>>
>>>> formlayout (generate option dialogs):
>>>> http://code.google.com/p/formlayout/
>>>>
>>>> pydee (IDE which integrates matplotlib and the option dialog):
>>>> http://code.google.com/p/pydee/
>>>> Meanwhile, thanks to the brand new Google-code Mercurial support, you
>>>> may browse the source code if you like:
>>>> http://code.google.com/p/pydee/source/browse/pydeelib/widgets/figureoptions.py
>>>>
>>>> Cheers,
>>>> Pierre
>>>>
>>>> ------------------------------------------------------------------------------
>>>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>>>> looking to deploy the next generation of Solaris that includes the latest
>>>> innovations from Sun and the OpenSource community. Download a copy and
>>>> enjoy capabilities such as Networking, Storage and Virtualization.
>>>> Go to: http://p.sf.net/sfu/opensolaris-get
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>
>>>
>>>
>>> --
>>> Gökhan
>>>
>>
>
>
>
> --
> Gökhan
>

Dear All,
I am trying to use the new 3D facilities offered by Matplotlib.
I know the mlab module of Mayavi, but I am interested in the vector 
export facilities offered by matplotlib.
Here is my issue : I can't manage to vary the color and/or size of the 
markers when doing 3D scatter plots :
fig = plt.figure()
ax = Axes3D(fig)
ax.scatter([1,2,3],[3,1,2],[1,2,0],c='r',s=[4,10,20])
The code above doesn't show size changes for each marker, just like :
ax.scatter([1,2,3],[3,1,2],[1,2,0])
Does anyone have an idea of what is going on ?
Thanks a lot,
luc
(I already posted this issue on the user list, but it seems to be a bug, 
and no one their seemed very interested in this issue either...)
---------------
luc Estebanez
Graduate Student,
ENS, Paris

Hi All,
I just spent an hour or two tracking down some problems with the 
buildbot test images that crept in unnoticed with the pdf backend 
testing. I think I now fixed all the issues with the buildbot testing, 
which required a few changes to the MPL source and a few on the buildbot 
server to build the image overview pages correctly. Anyhow, the image 
failure overview page is back to displaying useful information at 
http://mpl.code.astraw.com/overview.html
All this was prompted by a buildbot failure that occurred starting at 
r7958 or r7959, although these changes seem unlikely to be the cause of 
the issue. So, I'm a little mystified as to the actual cause, but it 
again looks like some freetype problem. Mike, do you think it could 
somehow be related to your recent font work?
-Andrew