matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> On Nov 14, 2007 1:53 PM, Ryan May <rm...@ou...> wrote:
>> Hi,
>>
>> Is there any reason that circles are approximated by polygons when
>> written out by vector graphics backends (i.e. SVG, PS)? Someone pointed
>> this out to me, and having verified it, I found it surprising. I would
>> think since at least SVG directly supports circles, they'd be used for
>> output.
> 
> This has been fixed in mpl svn for Agg and PS and will be included in
> the next release, but not yet for SVG. In the "transforms" branch,
> all supported backends (including Agg, PS and SVG draw "true" circles,
> and the plan is to merge these changes into the main trunk sometime
> after the next release.
On the branch, circles are actually approximated using cubic bezier 
curves. These apparently have a maximum radial error of less than 1e-3, 
so should be indistinguishable to the naked eye. I suspect that many 
rendering engines (e.g. Acrobat Reader) draw circles that way anyway for 
efficiency. But you still won't see "circle" elements in the SVG files.
This distinction is only important when you try to edit or analyse the 
resulting files -- since they aren't "logical" circles, a vector editor 
(e.g. inkscape), won't edit them as circles, but as paths. But since 
post-editing matplotlib plots is kind of problematic in a number of 
other ways, I don't know if that's a real problem.
(The point of all this is to reduce the number of required drawing 
commands in the backends to the lowest common denominator. You can draw 
virtually anything (with reasonable approximation) with polycurves, so 
that is now the only drawing primitive that mpl will ever output.)
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Nov 14, 2007 1:53 PM, Ryan May <rm...@ou...> wrote:
> Hi,
>
> Is there any reason that circles are approximated by polygons when
> written out by vector graphics backends (i.e. SVG, PS)? Someone pointed
> this out to me, and having verified it, I found it surprising. I would
> think since at least SVG directly supports circles, they'd be used for
> output.
This has been fixed in mpl svn for Agg and PS and will be included in
the next release, but not yet for SVG. In the "transforms" branch,
all supported backends (including Agg, PS and SVG draw "true" circles,
and the plan is to merge these changes into the main trunk sometime
after the next release.
JDH

On Nov 14, 2007, at 11:11 AM, Jeremy Conlin wrote:
> Mr. Waters,
>
> I read on the matplotlib mailing lists that you have compiled
> matplotlib on Leopard using libpng, freetype, etc. that are included
> with Leopard. I am trying to do the same, but have so far been
> unsuccessful. I could install those libraries from source, but would
> rather not. Would you mind sharing what you did to compile matplotlib
> with the included libraries?
I did this with a MacPorts build system. It checks out the matplotlib 
from subversion, applies some patches, then builds.
Ah, I built with Apple's pre-release GCC 4.2 for Leopard, which is 
available for ADC members... I have also built this with a "stock" GCC 
4.2.1, so you might be able to just get that compiler. And almost 
certainly it would work with Apple's GCC 4.0, but you'll have to 
remove the CFLAGS settings (see below).
Oh yes... I also didn't like the flags that Apple used to build 
Python; distutils has no way of overriding these and it breaks GCC 
4.2.x. So I used a 'fake' gcc that strips off the offending flags and 
then calls the 'real' compiler:
I used MacPorts to do all this. But here is a way that might work with 
a bash shell -- I'm just writing this down as an example, I haven't 
tested it, but this is sort of what I have in mind:
### ;;;;;;;;;;;;;;;;;;;;;;;;;;; cut here
mkdir mpl-devel
cd mpl-devel
cat > gccflt-4.2 <<EOF
#!/usr/bin/env python
# test with this at the command line
# ./gccflt-4.2 -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1
import sys
import os
realprog = "/usr/bin/gcc-4.2"
options_to_remove = set(['-no-cpp-precomp', '-Wno-long-double',
 '-mno-fused-madd', '-faltivec',
 ])
args = [a for a in sys.argv[1:] if a not in options_to_remove]
args.insert(0, '-fno-strict-aliasing')
print args
os.execvp(realprog, [realprog] + args)
EOF
sed -e 's,gcc-4.2,g++-4.2' < gccflt > g++flt
chmod +x gccflt
chmod +x g++flt
svn co http://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib 
 -r '{2007年10月25日}'
;
export CPPFLAGS=$(/usr/X11R6/bin/freetype-config --cflags)
export LDFLAGS=$(/usr/X11R6/bin/freetype-config --libs )
export ARCHFLAGS='-arch i386'
cd matplotlib
patch -p0 < ~/Desktop/patch-setupext.py
patch -p0 < ~/Desktop/patch-stdc++
python setup.py build
python setup.pu install
#;;;;;;;;;;;;;;;;;;;
#================================= end shell script
One of my targets is to make a "developer" build available - which 
means that my boss will be gently reminding me to provide this.
I was granted commit permissions on MacPorts, but have so far failed 
to commit my things back upstream to them; before Leopard I had really 
torn up their Python modules so that everything is deployed in a 
single /opt/local... tree. (I didn't put things in /Library).
With Leopard, if you want to use the system (Apple) Python, then I put 
things in /Library/Python/2.5/site-packages. I'm not sure that's the 
best thing to do. Initially it seems like no problem but we *always* 
run into conflicts, or want to have multiple versions available 
simultaneously...

Hi,
Is there any reason that circles are approximated by polygons when 
written out by vector graphics backends (i.e. SVG, PS)? Someone pointed 
this out to me, and having verified it, I found it surprising. I would 
think since at least SVG directly supports circles, they'd be used for 
output.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Nov 14, 2007 1:24 PM, Michael Droettboom <md...@st...> wrote:
> Coincidentally, I just noticed this myself, and fixed it (and renamed it
> to is_writable_file_like). There will be (once I commit), and handful
> of places that use it.
By the way, your changes to make all the backends support writing to
file-like objects is really nice. This is a *long* standing request,
particularly for web application developers, and will be very useful.
I was never able to figure out how to trick libpng into doing what I
wanted.
JDH

John Hunter wrote:
>> At the same time, I notice that cbook.is_file_like is identical to
>> is_string_like. This seems worse than useless to me. If we are going
>> to have "is_file_like" then it should do something like check for read
>> and write methods.
> 
> This looks like a bug. No other part of the code even calls it, so I
> removed it and noted it in API CHANGES
Coincidentally, I just noticed this myself, and fixed it (and renamed it 
to is_writable_file_like). There will be (once I commit), and handful 
of places that use it.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Nov 14, 2007 12:57 PM, Eric Firing <ef...@ha...> wrote:
> step_demo is failing because of this:
>
> In [4]:xx = numpy.ma.ones((2,3))
>
> In [5]:xx + ''
> Out[5]:array(NotImplemented)
>
A couple of days ago I was cleaning up references to Numeric and
numarray, and came across this
def is_string_like(obj):
 if hasattr(obj, 'shape'): return 0 # this is a workaround
 # for a bug in numeric<23.1
 try: obj + ''
 except (TypeError, ValueError): return 0
 return 1
Since we were no longer supporting Numeric, I figured this was
obsolete, and removed the hasattr check. It looks like we need it
still, so I readded it to svn
> Or, maybe there are places where we need to be using
> isinstance(x, (str, unicode))
> instead. Are there really cases where we need to detect something that
> is not a subclass of str or unicode, but that we can and should still
> treat as a string?
Yes, this comes up occasionally for people who have custom string
classes. With the exception of my recent "fix", it has been quite
robust.
> At the same time, I notice that cbook.is_file_like is identical to
> is_string_like. This seems worse than useless to me. If we are going
> to have "is_file_like" then it should do something like check for read
> and write methods.
This looks like a bug. No other part of the code even calls it, so I
removed it and noted it in API CHANGES
JDH

step_demo is failing because of this:
In [4]:xx = numpy.ma.ones((2,3))
In [5]:xx + ''
Out[5]:array(NotImplemented)
which makes cbook.is_string_like(xx) return True. This is a pitfall of 
duck-typing--sometimes something that quacks like duck is not a duck at all.
I can get back to this later, but maybe someone else can quickly think 
of a better non-hackish duck-typing test to use in is_string_like.
Or, maybe there are places where we need to be using
isinstance(x, (str, unicode))
instead. Are there really cases where we need to detect something that 
is not a subclass of str or unicode, but that we can and should still 
treat as a string?
At the same time, I notice that cbook.is_file_like is identical to 
is_string_like. This seems worse than useless to me. If we are going 
to have "is_file_like" then it should do something like check for read 
and write methods.
Eric

On Wed, Nov 14, 2007 at 08:59:15AM -0600, John Hunter wrote:
> Glen, this looks fairly benign (the center frequency bit) so I am
> happy to add it, but could I trouble you to make similar patch the
> other spectral methods as well (eg psd, csd and cohere) for the sake
> of consistency in the API?
Relax, patch attached.
Also, I am getting an error in numerix/__init__.py when it gets imported
by a script that is run by apache. Apparently, sys.argv has length 0,
so "del a" on line 38 fails.
Thanks,
Glen

On Nov 12, 2007 8:35 PM, Jarrod Millman <mi...@be...> wrote:
> I am willing to commit to helping migrating the relevant mlab code
> over to SciPy (or NumPy). The next release of SciPy
> (http://projects.scipy.org/scipy/scipy/milestone/0.7) may be pushed
> back a little, but it should be out by February at the latest. One of
> the things I had been planning to work on for this release was going
> over the various scipy.io code anyway.
>
> I probably won't get a chance to take a close look at things until
> December, but I thought I would mention it in case it has any impact
> on your own plans.
Thanks Jarrod, for the offer. I did another read-through of the mlab
stuff and it doesn't look like an unreasonable amount of work since a
lot of it is already deprecated. Some of it is geometry, like tests
whether segments intersect and that kind of thing, and belong in mpl
but probably another module. psd and csd will be needed to support
the plotting functions, so they will have to be in numpy or maptlotlib
since we don't rely on scipy. Some of the io stuff can go into scipy
or numpy. We'll reconvene in December when you have more time...
JDH

On Nov 14, 2007 8:00 AM, Michael Droettboom <md...@st...> wrote:
> I'll defer to others with more experience with specgram to assess the
> rest of your patch.
Glen, this looks fairly benign (the center frequency bit) so I am
happy to add it, but could I trouble you to make similar patch the
other spectral methods as well (eg psd, csd and cohere) for the sake
of consistency in the API?
JDH

The fix for mlab.py is obviously necessary, so I've committed it to SVN.
I'll defer to others with more experience with specgram to assess the 
rest of your patch.
Cheers,
Mike
Glen W. Mabey wrote:
> Hello,
> 
> This is fairly minor, but I'd wonder if you'd consider including it.
> 
> It adds an optional Fc parameter to the specgram method of the Axes
> class, and makes the calculation of the extent a bit more efficient.
> 
> Also, a quick fix for mlab.py.
> 
> Thank you,
> Glen Mabey
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

Thanks. This has been committed in SVN revision 4267, and will likely 
make it into the upcoming release.
Cheers,
Mike
Michael Zell wrote:
> Hi,
> 
> whenever I clicked the "save"-button in a plot in my TkAgg and pressed 
> "cancel" in the file dialog, I got the error message
> 
> Exception in Tkinter callback
> Traceback (most recent call last):
> File "lib-tk/Tkinter.py", line 1406, in __call__
> return self.func(*args)
> File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
> line 641, in save_figure
> bname, fext = os.path.splitext(fname)
> File "posixpath.py", line 92, in splitext
> i = p.rfind('.')
> AttributeError: 'tuple' object has no attribute 'rfind'
> 
> This obviously happened because tkFileDialog.asksaveasfilename returned 
> an empty tupel rather than an empty string, when the user cancels the 
> file dialog. I fixed it by replacing the line
> 
> if fname == "":
> 
> by
> 
> if fname == "" or fname == ():
> 
> in the file backend_tkagg.py.
> 
> Thank you,
> Michael Zell
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

Hi,
whenever I clicked the "save"-button in a plot in my TkAgg and pressed 
"cancel" in the file dialog, I got the error message
Exception in Tkinter callback
Traceback (most recent call last):
 File "lib-tk/Tkinter.py", line 1406, in __call__
 return self.func(*args)
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
line 641, in save_figure
 bname, fext = os.path.splitext(fname)
 File "posixpath.py", line 92, in splitext
 i = p.rfind('.')
AttributeError: 'tuple' object has no attribute 'rfind'
This obviously happened because tkFileDialog.asksaveasfilename returned 
an empty tupel rather than an empty string, when the user cancels the 
file dialog. I fixed it by replacing the line
if fname == "":
by
if fname == "" or fname == ():
in the file backend_tkagg.py.
Thank you,
Michael Zell