matplotlib-devel Mailing List for matplotlib (Page 3)

Phillip M. Feldman wrote:
> Jeff Whitaker wrote:
>> Phillip M. Feldman wrote:
>>> Andrew Straw wrote:
>>>> Jeff Whitaker wrote:
>>>> 
>>>>> Dr. Phillip M. Feldman wrote:
>>>>> 
>>>>>> Basemap offers many projections, but is missing two of the most 
>>>>>> useful ones:
>>>>>>
>>>>>> - For satellite applications, it would be helpful to have a "camera"
>>>>>> projection, i.e., a projection that shows the Earth as viewed from a
>>>>>> specified point in space. This would be a generalization of the 
>>>>>> current
>>>>>> geostationary projection.
>>>>>> 
>>>>> Philip: Don't think the proj4 lib supports this.
>>>>> 
>>>> I think it's already in there -- see nsper, for near sided 
>>>> perspective.
>>>>
>>>> -Andrew
>>>>
Philip: I've added the near-sided perspective projection to basemap svn 
- see the nsper_demo.py example. It only works if the earth is assumed 
to be a perfect sphere (no ellipsoids allowed).
-Jeff
>>>> 
>>> Hello Andrew-
>>>
>>> It does sound as thought nsper is exactly what I need, but when I 
>>> try to use it, I get the following error message:
>>>
>>> ValueError: 'nsper' is an unsupported projection.
>>> The supported projections are:
>>>
>>> aeqd Azimuthal Equidistant
>>> poly Polyconic
>>> gnom Gnomonic
>>> moll Mollweide
>>> tmerc Transverse Mercator
>>> nplaea North-Polar Lambert Azimuthal
>>> gall Gall Stereographic Cylindrical
>>> mill Miller Cylindrical
>>> merc Mercator
>>> stere Stereographic
>>> npstere North-Polar Stereographic
>>> geos Geostationary
>>> vandg van der Grinten
>>> laea Lambert Azimuthal Equal Area
>>> mbtfpq McBryde-Thomas Flat-Polar Quartic
>>> sinu Sinusoidal
>>> spstere South-Polar Stereographic
>>> lcc Lambert Conformal
>>> npaeqd North-Polar Azimuthal Equidistant
>>> eqdc Equidistant Conic
>>> cyl Cylindrical Equidistant
>>> omerc Oblique Mercator
>>> aea Albers Equal Area
>>> spaeqd South-Polar Azimuthal Equidistant
>>> ortho Orthographic
>>> cass Cassini-Soldner
>>> splaea South-Polar Lambert Azimuthal
>>> robin Robinson
>>>
>>> Phillip 
>> Philip: I think Andrew meant nsper is in proj4. I'll look into 
>> adding support for it in Basemap.
>>
>> -Jeff
>>
> Thanks!
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Hi MPL developers,
I use an older matplotlib version but this code is the same in SVN, so I thought
I'll mention it.
Thanks,
Nadia
In [1]: from matplotlib import pyplot as plt
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
/tangra/data1/dev/spectra/center1d/center1d/matplotlib/__init__.py in <module>()
 149 if not (int(nn[0]) >= 1 and int(nn[1]) >= 1):
 150 raise ImportError(
--> 151 'numpy 1.1 or later is required; you have %s' % 					 
numpy.__version__)
 152
 153 def is_string_like(obj):
ImportError: numpy 1.1 or later is required; you have 2.0.0.dev8107

Brian32 wrote:
> Hello,
>
> I am currently displaying plots on a web page using matplotlib by creating
> .png files. I would like have the ability for people to have access to the
> interactive plot feature (Zoom,Save) when they look at the plots on the web
> page. I do not care if the plot is a pop up or if is directly on the web
> page. At this point I just want the interactive feature available. I am
> assuming that the end user that clicks on a web link will already have
> python/matplotlib installed. Does anyone know if this is even possible? If
> it is I would love to see an example of this. 
>
> Thanks in advance,
> Brian 
> 
I think you might be interesting in something like a javascript charting
library. This webpage lists some interesting options:
http://www.alsonkemp.com/tools/highcharts-javascript-charting-library/

PH...@Ge... wrote:
>> PH...@Ge... wrote:
>> 
>>> Hey folks,
>>>
>>> I recently modified the Axes method boxplot so that the confidence
>>> 
>> intervals around the mean are computed not with a static formula, but by
>> bootstrapping the median as many times as the user specifies. Also, I
>> commented out the lines that prevent the boxplots from folding around the
>> hinges (but that's obviously minor and in the current SVN if I'm not
>> mistaken).
>> 
>>> Is this something that would be worth including in matplotlib? I've
>>> 
>> never contributed to a project like this before and my code is probably
>> pretty sloppy by MPL standards. I'm not really sure what's appropriate to
>> contribute and what's not.
>> 
>
>
> 
>> -----Original Message-----
>> From: Andrew Straw [mailto:str...@as...]
>> Sent: Wednesday, February 10, 2010 2:20 PM
>> To: Paul Hobson
>> Cc: mat...@li...
>> Subject: Re: [matplotlib-devel] Boxplots with Bootstrapped Intervals
>> ...
>> I think the best thing to do is to post the patch so that it can be
>> reviewed. Sending the output of "svn diff" as an attachment to this
>> email list would be easy from our end. (A github based submission --
>> fork the repo and push your commits -- would also work well for me, but
>> I'm not sure about the other MPL devs.)
>> 
>
> Andrew,
>
> Thanks for the reply. At the risk of embarrassment, I'm going to admit that I'm not at all familiar with SVN other than I know that it's version control software. Nonetheless I gave it a shot.
>
> I guess I should add that I didn't account for the fact that the user might want to have the CIs output with the other boxplot properties. Shouldn't be too hard to add in though. Also, I'm using the percentile method -- meaning that after I get my "normal" distribution of medians, I simply use mlab's percentile function to get the 2.5th and 97.5th percentile of that distribution. The other method (bias-corrected and accelerated) was too complex for me to code up quickly without using Rpy2, and that just seemed silly.
> 
Hi Paul,
I committed a modified version of your code in r8127. This new code is
backwards compatible in the sense that it doesn't change anything for
existing uses of boxplot, but allows use of the bootstrapped approach by
specifying "notch=1" and "bootstrap=N" where N is the number of
resampling steps.
Thanks,
Andrew

Hello,
I am currently displaying plots on a web page using matplotlib by creating
.png files. I would like have the ability for people to have access to the
interactive plot feature (Zoom,Save) when they look at the plots on the web
page. I do not care if the plot is a pop up or if is directly on the web
page. At this point I just want the interactive feature available. I am
assuming that the end user that clicks on a web link will already have
python/matplotlib installed. Does anyone know if this is even possible? If
it is I would love to see an example of this. 
Thanks in advance,
Brian 
-- 
View this message in context: http://old.nabble.com/Display-Interactive-plots-on-a-web-page--tp27550397p27550397.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

> PH...@Ge... wrote:
> > Hey folks,
> >
> > I recently modified the Axes method boxplot so that the confidence
> intervals around the mean are computed not with a static formula, but by
> bootstrapping the median as many times as the user specifies. Also, I
> commented out the lines that prevent the boxplots from folding around the
> hinges (but that's obviously minor and in the current SVN if I'm not
> mistaken).
> >
> > Is this something that would be worth including in matplotlib? I've
> never contributed to a project like this before and my code is probably
> pretty sloppy by MPL standards. I'm not really sure what's appropriate to
> contribute and what's not.
> >
> -----Original Message-----
> From: Andrew Straw [mailto:str...@as...]
> Sent: Wednesday, February 10, 2010 2:20 PM
> To: Paul Hobson
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] Boxplots with Bootstrapped Intervals
> ...
> I think the best thing to do is to post the patch so that it can be
> reviewed. Sending the output of "svn diff" as an attachment to this
> email list would be easy from our end. (A github based submission --
> fork the repo and push your commits -- would also work well for me, but
> I'm not sure about the other MPL devs.)
Andrew,
Thanks for the reply. At the risk of embarrassment, I'm going to admit that I'm not at all familiar with SVN other than I know that it's version control software. Nonetheless I gave it a shot.
I guess I should add that I didn't account for the fact that the user might want to have the CIs output with the other boxplot properties. Shouldn't be too hard to add in though. Also, I'm using the percentile method -- meaning that after I get my "normal" distribution of medians, I simply use mlab's percentile function to get the 2.5th and 97.5th percentile of that distribution. The other method (bias-corrected and accelerated) was too complex for me to code up quickly without using Rpy2, and that just seemed silly.
Thanks again,
-paul

PH...@Ge... wrote:
> Hey folks,
>
> I recently modified the Axes method boxplot so that the confidence intervals around the mean are computed not with a static formula, but by bootstrapping the median as many times as the user specifies. Also, I commented out the lines that prevent the boxplots from folding around the hinges (but that's obviously minor and in the current SVN if I'm not mistaken). 
>
> Is this something that would be worth including in matplotlib? I've never contributed to a project like this before and my code is probably pretty sloppy by MPL standards. I'm not really sure what's appropriate to contribute and what's not.
> 
Hi Paul,
This sounds interesting.
I think the best thing to do is to post the patch so that it can be
reviewed. Sending the output of "svn diff" as an attachment to this
email list would be easy from our end. (A github based submission --
fork the repo and push your commits -- would also work well for me, but
I'm not sure about the other MPL devs.)
-Andrew

Hey folks,
I recently modified the Axes method boxplot so that the confidence intervals around the mean are computed not with a static formula, but by bootstrapping the median as many times as the user specifies. Also, I commented out the lines that prevent the boxplots from folding around the hinges (but that's obviously minor and in the current SVN if I'm not mistaken). 
Is this something that would be worth including in matplotlib? I've never contributed to a project like this before and my code is probably pretty sloppy by MPL standards. I'm not really sure what's appropriate to contribute and what's not.
Regards,
-paul h.

Hi folks,
the message below is an important discussion on which we'd like
feedback/ideas both from Enthought.traits experts and matplotlib ones.
 It would be great if we could keep things in one list, so it seems
most sensible to hold the discussion in the ipython-dev list, but this
is a heads-up in case one of you is interested but may not monitor
ipython-dev.
Thanks!
f
---------- Forwarded message ----------
From: Brian Granger <ell...@gm...>
Date: Tue, Feb 9, 2010 at 11:59 PM
Subject: [IPython-dev] GUI support: conflicts between IPython 0.11 and
Matplotlib/ETS
To: IPython Development list <ipy...@sc...>
Hello all,
As many of you know, we have been working hard on IPython 0.11. One
of the big new features of 0.11 is a refactored integration with GUI
event loops.
We are very excited about this as it is much more stable and add new
capabilities, like being able to enable pylab *after* starting IPython
(it is a magic: %pylab).
BUT, as Fernando and I have started to use the IPython 0.11 alpha for
our daily work, we have found some subtle issue with IPython 0.11 and
the current
versions of matplotlib and Enthought tool suite (traits, chaco,
mayavi). All of these packages rely on IPython's previous way of
handling GUI
integration. Because of this, current versions of matplotlib and ets
don't work fully with IPython 0.11. In some cases, they work OK, but
there are a whole class
of bugs that keep popping up. We don't want to release IPython 0.11
until these issues are resolved.
All of these bugs are related to a few aspects of creating the main
GUI app objects and starting event loops. We think we understand the
issues, but we will
need to work with the devs of matplotlib and ets to decide on how we
all want to handle these things. Here is where we are at...
Current situation
=============
Both matplotlib and ets have code that tries to:
* See what GUI toolkit is being used
* Get the global App object if it already exists, if not create it.
* See if the main loop is running, if not possibly start it.
All of this logic makes many assumptions about how IPython affects the
answers to these
questions. Because IPython's GUI support has changed in significant
ways, current matplotlib
and ets make incorrect decisions about these issues (such as trying to
start the event loop
a second time, creating a second main App ojbect, etc.) under IPython
0.11. This leads to crashes...
Description of GUI support in 0.11
==========================
IPython allows GUI event loops to be run in an interactive IPython session.
This is done using Python's PyOS_InputHook hook which Python calls
when the :func:`raw_input` function is called and is waiting for user input.
IPython has versions of this hook for wx, pyqt4 and pygtk. When the inputhook
is called, it iterates the GUI event loop until a user starts to type
again. When
the user stops typing, the event loop iterates again. This is how tk works.
When a GUI program is used interactively within IPython, the event loop of
the GUI should *not* be started. This is because, the PyOS_Inputhook itself
is responsible for iterating the GUI event loop.
IPython has facilities for installing the needed input hook for each GUI
toolkit and for creating the needed main GUI application object. Usually,
these main application objects should be created only once and for some
GUI toolkits, special options have to be passed to the application object
to enable it to function properly in IPython.
What we need to decide
===================
We need to answer the following questions:
* Who is responsible for creating the main GUI application object, IPython
 or third parties (matplotlib, enthought.traits, etc.)?
* What is the proper way for third party code to detect if a GUI application
 object has already been created? If one has been created, how should
 the existing instance be retrieved?
* In a GUI application object has been created, how should third party code
 detect if the GUI event loop is running. It is not sufficient to call the
 relevant function methods in the GUI toolkits (like ``IsMainLoopRunning``)
 because those don't know if the GUI event loop is running through the
 input hook.
* We might need a way for third party code to determine if it is running
 in IPython or not. Currently, the only way of running GUI code in IPython
 is by using the input hook, but eventually, GUI based versions of IPython
 will allow the GUI event loop in the more traditional manner. We will need
 a way for third party code to distinguish between these two cases.
Thanks for participating in this discussion!
Cheers,
Brian
_______________________________________________
IPython-dev mailing list
IPy...@sc...
http://mail.scipy.org/mailman/listinfo/ipython-dev

Hi - mea culpa - as pointed out by a colleague (and documented in the help
document for "hanning" in Matlab), this function produces the same window,
but without the first and last zero-weighted samples.
Cheers -- Ariel
On Tue, Feb 9, 2010 at 4:58 PM, Ariel Rokem <ar...@be...> wrote:
> Hi everyone,
>
> Mystery solved (I think)! It turns out that matlab has two functions, one
> called "hann" and the other called "hanning". They both purport to produce
> the hanning window, but they produce two (slightly) different things. Only
> one of these (the one given by "hann") actually produces the hanning window
> as it is defined in the standard reference on this (Harris 1978. And also
> Wikipedia ;D). When using the "hann" function in Matlab in this little
> experiment, the difference between the python and the matlab results, is on
> the order of %10e-6. I think I am willing to live with that.
>
> The only mystery that remains (I think) is - what is Matlab's "hanning"
> supposed to be doing? Are there two different windows: hann and hanning (not
> "hamming" - I know that's a different one)?
>
> Cheers,
>
> Ariel
>
>
> On Mon, Feb 8, 2010 at 9:32 AM, Ariel Rokem <ar...@be...> wrote:
>
>> Hi -
>>
>> the maximal difference in this case is of about 6 (units?), which is an
>> approximately 50% difference. This is in one point in the spectrum which has
>> a relatively small value - the maximal peaks in the spectra are on the order
>> of 1200, so in the grand scheme of things, not that horrible. Other large
>> differences are on the order of 4, which is approximately 5% or less of
>> those points.
>>
>> Thanks - Ariel
>>
>> PS for some reason, matplotlib-devel will not get your email unless you
>> hit "reply all", so they have been getting my emails, but not yours. I am
>> not sure whether that is what you intended, so I thought I would mention it.
>>
>>
>>
>> On Mon, Feb 8, 2010 at 1:24 AM, Ludwig Schwardt <
>> lud...@gm...> wrote:
>>
>>> Hi,
>>>
>>> On Mon, Feb 8, 2010 at 5:25 AM, Ariel Rokem <ar...@be...> wrote:
>>> > I don't think that the cause of the discrepancy is because of the
>>> > hamming/hanning window difference. I do set the window in the matlab
>>> part to
>>> > also be a hanning window of length nfft.
>>>
>>> I suspected you gave the same window to both, but I was just
>>> checking... :-) To find those smaller discrepancies might be a bit
>>> harder then, requiring a careful comparison of the various steps
>>> involved. Just for interest's sake, how big are the differences we are
>>> talking about?
>>>
>>> Regards,
>>> Ludwig
>>>
>>
>>
>>
>> --
>> Ariel Rokem
>> Helen Wills Neuroscience Institute
>> University of California, Berkeley
>> http://argentum.ucbso.berkeley.edu/ariel
>>
>
>
>
> --
> Ariel Rokem
> Helen Wills Neuroscience Institute
> University of California, Berkeley
> http://argentum.ucbso.berkeley.edu/ariel
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel

Hi everyone,
Mystery solved (I think)! It turns out that matlab has two functions, one
called "hann" and the other called "hanning". They both purport to produce
the hanning window, but they produce two (slightly) different things. Only
one of these (the one given by "hann") actually produces the hanning window
as it is defined in the standard reference on this (Harris 1978. And also
Wikipedia ;D). When using the "hann" function in Matlab in this little
experiment, the difference between the python and the matlab results, is on
the order of %10e-6. I think I am willing to live with that.
The only mystery that remains (I think) is - what is Matlab's "hanning"
supposed to be doing? Are there two different windows: hann and hanning (not
"hamming" - I know that's a different one)?
Cheers,
Ariel
On Mon, Feb 8, 2010 at 9:32 AM, Ariel Rokem <ar...@be...> wrote:
> Hi -
>
> the maximal difference in this case is of about 6 (units?), which is an
> approximately 50% difference. This is in one point in the spectrum which has
> a relatively small value - the maximal peaks in the spectra are on the order
> of 1200, so in the grand scheme of things, not that horrible. Other large
> differences are on the order of 4, which is approximately 5% or less of
> those points.
>
> Thanks - Ariel
>
> PS for some reason, matplotlib-devel will not get your email unless you hit
> "reply all", so they have been getting my emails, but not yours. I am not
> sure whether that is what you intended, so I thought I would mention it.
>
>
> On Mon, Feb 8, 2010 at 1:24 AM, Ludwig Schwardt <lud...@gm...
> > wrote:
>
>> Hi,
>>
>> On Mon, Feb 8, 2010 at 5:25 AM, Ariel Rokem <ar...@be...> wrote:
>> > I don't think that the cause of the discrepancy is because of the
>> > hamming/hanning window difference. I do set the window in the matlab
>> part to
>> > also be a hanning window of length nfft.
>>
>> I suspected you gave the same window to both, but I was just
>> checking... :-) To find those smaller discrepancies might be a bit
>> harder then, requiring a careful comparison of the various steps
>> involved. Just for interest's sake, how big are the differences we are
>> talking about?
>>
>> Regards,
>> Ludwig
>>
>
>
>
> --
> Ariel Rokem
> Helen Wills Neuroscience Institute
> University of California, Berkeley
> http://argentum.ucbso.berkeley.edu/ariel
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel

I believe the bug actually is in matplotlib, and recent ghostscript versions fail only because they have become stricter over time. The TTF-to-Postscript font conversion library in matplotlib (ttconv) was hard-coded to use the "Standard" Postscript encoding (which defines the set of glyphs available for use), and "Standard" doesn't include the "/minus" sign. This confuses ghostscript when it tries to convert a Type 3 Postscript font to a Type 3 PDF font. Since detecting the correct "built-in" encoding to use when converting an arbitrary TTF file is rather tricky (and matplotlib can use some pretty esoteric Unicode characters when drawing math expressions), my workaround is to create a custom encoding for each font, containing only the glyphs actually being used. Postscript has a limitation of 255 glyphs per font in a custom encoding, but in practice it should be difficult to hit this. Surprisingly (to me at least), using a wacky arbitrary encoding doesn't break the Find/R!
!
eplace and accessibility functions on the resulting PDF file.
So, this is now fixed in SVN trunk, I believe. As a workaround for released versions of matplotlib, you can set ps.fonttype to 42 which sidesteps the whole Type 3 font subsetting/encoding issue. At least on my machine, I had no trouble converting a PS file with Type 42 fonts to a PDF with ps2pdf/gs 8.70.
Thanks for your help tracking this down.
Mike

I just committed Ariel's csd changes to the 99 branch, and when I
attempted to merge I first got a failure and now the branch is not
showing up in the available branches. Any ideas? The branch was
listed on a 'svnmerge.py merge' command *before* the failure.
jdhunter@uqbar:mpl> svnmerge.py merge
/home/jdhunter/dev/bin/svnmerge.py:71: DeprecationWarning: The popen2
module is deprecated. Use the subprocess module.
 import sys, os, getopt, re, types, tempfile, time, popen2, locale
svnmerge: multiple sources found. Explicit source argument
(-S/--source) required.
The merge sources available are:
 /branches/v0_99_maint
 /branches/mathtex
jdhunter@uqbar:mpl> svnmerge.py merge -Sv0_99_maint
/home/jdhunter/dev/bin/svnmerge.py:71: DeprecationWarning: The popen2
module is deprecated. Use the subprocess module.
 import sys, os, getopt, re, types, tempfile, time, popen2, locale
property 'svnmerge-integrated' set on '.'
svnmerge: command execution failed (exit code: 1)
svn --non-interactive propdel "svnmerge-blocked" "."
svn: Attempting to delete nonexistent property 'svnmerge-blocked'
jdhunter@uqbar:mpl> svnmerge.py merge -Sv0_99_maint
/home/jdhunter/dev/bin/svnmerge.py:71: DeprecationWarning: The popen2
module is deprecated. Use the subprocess module.
 import sys, os, getopt, re, types, tempfile, time, popen2, locale
svnmerge: "v0_99_maint" is neither a valid URL, nor an unambiguous
substring of a repository path, nor a working directory
jdhunter@uqbar:mpl> svnmerge.py merge
/home/jdhunter/dev/bin/svnmerge.py:71: DeprecationWarning: The popen2
module is deprecated. Use the subprocess module.
 import sys, os, getopt, re, types, tempfile, time, popen2, locale
svnmerge: multiple sources found. Explicit source argument
(-S/--source) required.
The merge sources available are:
 /branches/v0_91_maint
 /branches/mathtex
 /branches/v0_98_5_maint

Hi -
the maximal difference in this case is of about 6 (units?), which is an
approximately 50% difference. This is in one point in the spectrum which has
a relatively small value - the maximal peaks in the spectra are on the order
of 1200, so in the grand scheme of things, not that horrible. Other large
differences are on the order of 4, which is approximately 5% or less of
those points.
Thanks - Ariel
PS for some reason, matplotlib-devel will not get your email unless you hit
"reply all", so they have been getting my emails, but not yours. I am not
sure whether that is what you intended, so I thought I would mention it.
On Mon, Feb 8, 2010 at 1:24 AM, Ludwig Schwardt
<lud...@gm...>wrote:
> Hi,
>
> On Mon, Feb 8, 2010 at 5:25 AM, Ariel Rokem <ar...@be...> wrote:
> > I don't think that the cause of the discrepancy is because of the
> > hamming/hanning window difference. I do set the window in the matlab part
> to
> > also be a hanning window of length nfft.
>
> I suspected you gave the same window to both, but I was just
> checking... :-) To find those smaller discrepancies might be a bit
> harder then, requiring a careful comparison of the various steps
> involved. Just for interest's sake, how big are the differences we are
> talking about?
>
> Regards,
> Ludwig
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel

Agg backends (in addition to the ps backend) now support
affine-transformed image.
Regards,
-JJ
On Thu, Dec 17, 2009 at 7:05 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Thu, Dec 17, 2009 at 5:03 PM, Andrew Straw <str...@as...> wrote:
>> It's not clear to me if this proposal lets one specify any arbitrary affine
>> transformation. Does it?
>
> I believe it does. 3 coordinates will define 6 equations where we have
> 6 unknowns of the affine matrix.
> The question is how user want to specify the transform.
> The extended extent keyword would be useful for the cases like the
> pseudo-perspective projection that you mentioned. But, it will not be
> very convenient for the cases like simple rotation.
>
>
>>
>> In general -- very nice. Thanks.
>>
>> In specific, I think the way you have already implemented things is
>> sufficient. I think if a user can write a little helper function (as in your
>> demo) to avoid a dumbed-down API being part of MPL, that would be best.
>> Anyone specifying their own affine transform is probably going to want a
>> pretty precise level of control, anyway. (Of course if your extent keyword
>> proposal is already a general purpose API, then please ignore this comment.)
>
> I, personally, don't like the idea that user needs to define his/her
> own transform to rotate/skew the image. Rotation and skew seems more
> like properties of the image, rather than the transform.
>
> Anyhow, unless others step in, I may leave it as is (partially because
> I don't have much use case for rotated/skewed images for now). And, I
> hope someone implement similar affine transform for other backends.
> For the backends that requires resampling (agg, etc.), it might be
> better if the affine transform is taken care during the resampling
> (i.e., in the Image.draw method) rather than to be delegated to the
> backends.
>
> Regards,
>
> -JJ
>
>>
>> -Andrew
>>
>

Thanks for reporting this. I wasn't aware of the issue.
Since I don't have a libpng-1.4 to verify the fix with, are you able to checkout from SVN trunk and test it?
Mike

Hi Ludwig (responding also to list),
I don't think that the cause of the discrepancy is because of the
hamming/hanning window difference. I do set the window in the matlab part to
also be a hanning window of length nfft.
Cheers,
Ariel
On Sun, Feb 7, 2010 at 7:45 AM, Ludwig Schwardt
<lud...@gm...>wrote:
> Hi,
>
> On Sun, Feb 7, 2010 at 12:46 AM, Ariel Rokem <ar...@be...> wrote:
> > I don't think that a major reworking of the logic of the function is
> needed.
> > Simply replacing the line you mentioned with:
> >
> > Pxy *= 1 / (np.abs(windowVals)**2).sum()
> > Pxy[1:-1] *= scaling_factor
> > if scale_by_freq:
> > Pxy[[0,-1]] /= Fs
>
> I agree. I was hoping the first two lines above would be sufficient.
> Then I saw scaling_factor also included Fs if scaling by frequency,
> and Pxy is of shape (numFreqs,n), i.e. not a straightforward 1-D
> array, which caused me to reserve my judgment a little bit... :-)
>
> > What does become more apparent when I do that is that in frequency bands
> in
> > which the power is rather small, the ratio discrepancies between the mlab
> > result and the matlab result can be rather large, on the order of a
> factor
> > of 2-2.5, even when the differences are tiny. Similarly, when the power
> is
> > rather large, there can be non-negligible differences between the two
> > results. Is there anything to do about that?
>
> Could this be because Matlab uses a Hamming window by default, while
> mlab uses a *Hanning* window by default? Very similar-sounding names,
> and also very similar windows numerically (but not exactly the
> same)...
>
> Ludwig
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel

Am Samstag, den 06.02.2010, 14:02 -1000 schrieb Eric Firing:
> Benjamin Drung wrote:
> > Hi,
> > 
> > we applied 40_hurd.patch for building matplotlib on Debian GNU/Hurd.
> > 
> > Additional attached the 10_build_fix.patch. This patch does two things.
> > First it enables matplotlib on all Debian architectures. The second
> > things is that it removes /usr/local from the basedir.
> > 
> > It would be nice if you can provide a configure flag for disabling
> > the /usr/local directory from the basedir. Then we can drop this patch.
> > 
> 
> Sorry, I dropped this the last time you brought it up. I have now added 
> gnu0 as a platform, and added a "basedirlist" option to setup.cfg. See 
> svn r8113 and 8115.
Thanks.
-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)

Benjamin Drung wrote:
> Hi,
> 
> we applied 40_hurd.patch for building matplotlib on Debian GNU/Hurd.
> 
> Additional attached the 10_build_fix.patch. This patch does two things.
> First it enables matplotlib on all Debian architectures. The second
> things is that it removes /usr/local from the basedir.
> 
> It would be nice if you can provide a configure flag for disabling
> the /usr/local directory from the basedir. Then we can drop this patch.
> 
Sorry, I dropped this the last time you brought it up. I have now added 
gnu0 as a platform, and added a "basedirlist" option to setup.cfg. See 
svn r8113 and 8115.
The linux2-alpha etc platforms were already there.
Eric

I just committed the changes.
Regards,
-JJ
On Wed, Jan 27, 2010 at 2:31 PM, Eric Firing <ef...@ha...> wrote:
> Jae-Joon Lee wrote:
>>
>> On Mon, Jan 25, 2010 at 7:19 PM, Jae-Joon Lee <lee...@gm...>
>> wrote:
>>>
>>> Adding a "set_ticks" method seems reasonable.
>>
>> A patch is attached.
>
> It looks like exactly what I had in mind with respect to set_ticks. I
> wasn't thinking about set_ticklabels; my sense is that manually setting
> ticklabels tends to be tricky and error-prone, and should be discouraged.
> Maybe it should be permitted only when a FixedLocator is already in use.
>
>> It does some refactoring and introduces three new methods, set_ticks,
>> set_ticklabels and update_ticks, on the colorbar class.
>> So, now one can do
>>
>> imshow(np.arange(100).reshape((10,10)))
>> cb = colorbar()
>> cb.set_ticks([0, 40, 80])
>>
>> Issuing a warning when user try to call Axis.set_ticks (or others)
>> directly seems not straight forward as the axes can be created
>> externally (i.e., when *cax* is provided).
>
> Attached patch against svn (without your patch) shows how this can be done
> for the Axes methods. I would be more difficult (but not impossible) for
> the Axis methods, because we need to use them. I think that handling the
> Axes methods *may* be worthwhile (marginal), but handling the Axis methods
> is more trouble than it is worth.
>
> Eric
>
>>
>> I'll wait for response for a few more days and will commit the change.
>> Regards,
>>
>> -JJ
>
>

Hi,
we applied 40_hurd.patch for building matplotlib on Debian GNU/Hurd.
Additional attached the 10_build_fix.patch. This patch does two things.
First it enables matplotlib on all Debian architectures. The second
things is that it removes /usr/local from the basedir.
It would be nice if you can provide a configure flag for disabling
the /usr/local directory from the basedir. Then we can drop this patch.
-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)

Hi,
> From: Ariel Rokem <ar...@be...>
> However - two elements are off by a factor of approximately 2 - the
> very first element and the very last. ... Does anyone have any idea
> why this would be the case?
>From a quick look at the mlab code, it looks like a bug in
mlab._spectral_helper.
The default spectrum is 'onesided' (same as for Matlab's cpsd). A
single-sided spectrum of a real signal has double the magnitude of a
double-sided spectrum, *except* at the origin (frequency index n = 0)
and Nyquist frequency (n = NFFT / 2), where it is the *same* as the
double-sided one [1]_.
In the mlab code, all the spectral values are simply scaled by a
factor of 2 (among other factors) in this line:
 # Scale the spectrum by the norm of the window to compensate for
 # windowing loss; see Bendat & Piersol Sec 11.5.2. Also include
 # scaling factors for one-sided densities and dividing by the sampling
 # frequency, if desired.
 Pxy *= scaling_factor / (np.abs(windowVals)**2).sum()
This should be easy to fix (although the function probably needs a
little rework).
Regards,
Ludwig
Quick reference from my bookshelf:
---------------------------------------------------
.. [1] W. L. Briggs, V. E. Henson, "The DFT: An Owner's Manual for the
Discrete Fourier Transform," Section 1.3, Problem 6 (a), p. 13.

This is probably already known, but I'll go ahead and post it. In trying to build against libpng-1.4.0, I had to edit src/_png.cpp:
// png_destroy_read_struct(&png_ptr, &info_ptr, png_infopp_NULL);
 png_destroy_read_struct(&png_ptr, &info_ptr, NULL);
-Randy

 8.9429666e+00 5.0100717e+00 -2.6816087e+00 -7.1501559e+00 -8.0216237e+00 -8.4308386e+00 -8.7813313e+00 -7.1541340e+00 -3.1692794e+00 -3.1233587e-02 -8.6932796e-01 -3.2208590e+00 -2.7708292e+00 -1.1180497e+00 -1.1642218e+00 8.2827157e-01 7.7567196e+00 1.3427191e+01 1.2297869e+01 7.9463857e+00 4.3650450e+00 7.4513721e-01 -1.8071566e+00 -1.0494220e+00 2.7099914e-01 -6.0612992e-03 1.0650746e+00 2.7359840e+00 -2.3103312e-01 -5.4394070e+00 -5.6020012e+00 -2.8549610e+00 -3.9441985e+00 -6.5248611e+00 -5.5182498e+00 -3.5707725e+00 -3.3029199e+00 -1.4821612e+00 1.9829637e+00 2.9371484e+00 2.4922181e+00 4.6520641e+00 7.6516172e+00 7.9849900e+00 6.2872303e+00 3.0524810e+00 -2.6249618e+00 -8.4729269e+00 -1.1423490e+01 -1.1515627e+01 -8.0828989e+00 -6.1605087e-02 7.3546053e+00 7.3762039e+00 2.7203112e+00 9.7107193e-01 2.3389000e+00 2.3308435e+00 1.0908653e+00 1.3983531e+00 2.7507814e+00 3.1877024e+00 2.6855553e+00 2.0890036e+00 1.5431800e+00 2.6735579e-01 -2.8915636e+00 -6.9616787e+00 -7.7022941e+00 -2.6552425e+00 3.6478430e+00 4.5449371e+00 9.1741479e-01 -1.0349366e-01 3.1044471e+00 3.5481921e+00 -2.7689468e+00 -9.5888143e+00 -9.2968371e+00 -3.1434409e+00 1.4650620e+00 4.9126975e-02 -4.4859946e+00 -5.1590780e+00 1.6118592e-01 4.9388060e+00 4.1399337e+00 3.0802173e+00 7.1234314e+00 1.0353879e+01 6.3260927e+00 5.0624656e-01 -4.3675968e-01 -2.3225964e-01 -2.4186513e+00 -1.9095391e+00 2.5966116e+00 3.2187007e+00 -1.6422521e+00 -2.9320855e+00 1.4858112e+00 2.1743862e+00 -3.8657803e+00 -7.4941826e+00 -3.6778977e+00 1.4465903e+00 2.0995855e+00 -3.6925935e-01 -2.4488424e+00 -2.2657275e+00 -3.0767826e-01 -4.3447784e-02 -3.7835013e+00 -7.7710751e+00 -6.6156223e+00 -9.8452194e-01 3.6143927e+00 3.3559741e+00 -7.0214935e-01 -4.0464556e+00 -3.4005198e+00 3.1925151e-01 5.6106943e+00 1.2129909e+01 1.5598452e+01 1.0761346e+01 2.7808335e+00 1.6264690e+00 4.3371698e+00 6.9655189e-01 -6.4917108e+00 -7.1557533e+00 -3.2903321e+00 -2.5653037e+00 -2.8456560e+00 -3.8648126e-01 -3.4792857e-01 -5.4706976e+00 -8.4354584e+00 -4.7666552e+00 1.1698809e-01 1.4126243e+00 5.2560707e-01 -1.2557422e+00 -4.3464817e+00 -6.0548728e+00 -2.6022608e+00 3.4128104e+00 4.5097622e+00 -6.8046372e-01 -4.1244079e+00 -2.6499816e-02 6.5978997e+00 8.9300310e+00 8.9028673e+00 1.0882147e+01 1.1960235e+01 7.5608590e+00 3.1334125e-01 -4.6417949e+00 -6.9282767e+00 -7.4717365e+00 -4.8990327e+00 -5.8542748e-01 -8.4564434e-02 -4.8146391e+00 -8.9187473e+00 -8.1146069e+00 -5.1477694e+00 -3.2111192e+00 -7.1163877e-01 3.6409206e+00 6.6594649e+00 5.8487425e+00 3.7533921e+00 3.2460105e+00 2.9353594e+00 1.0668831e+00 -5.3054098e-01 -4.1149627e-01 -8.1327290e-01 -3.0706932e+00 -4.5485475e+00 -3.4206624e+00 -1.2170184e+00 9.6882742e-01 2.7440724e+00 1.8368024e+00 -1.5910131e+00 -2.0317113e+00 2.4423217e+00 5.2609099e+00 2.5027442e+00 -5.3925455e-01 3.6824003e-01 2.1030815e+00 1.6465455e+00 8.1607062e-02 -1.1482050e+00 -9.4266580e-01 1.0252083e+00 1.3283382e+00 -2.8992882e+00 -7.2661102e+00 -6.6027869e+00 -3.7400399e+00 -2.6018526e+00 -2.3601345e-01 5.1733118e+00 7.6959332e+00 3.2229165e+00 -3.2443397e+00 -5.6303607e+00 -3.8377406e+00 2.4645472e-01 5.0569136e+00 6.3004349e+00 1.3203384e+00 -3.1151906e+00 1.3232982e+00 9.5677298e+00 9.5030932e+00 1.5131090e+00 -3.8561271e+00 -4.4258970e+00 -5.7326471e+00 -7.0638856e+00 -4.7194733e+00 -2.2836642e+00 -3.3429743e+00 -2.5434213e+00 4.5252898e+00 1.1170906e+01 8.4467296e+00 -1.3827260e+00 -6.9978902e+00 -3.0066829e+00 2.8550972e+00 2.1056966e+00 -1.6739241e+00 -1.9125812e+00 -1.2343693e+00 -2.3238766e+00 3.4253954e-02 6.2718152e+00 8.3409736e+00 5.4121519e+00 3.9103398e+00 2.6471453e+00 -2.2564369e+00 -5.9685791e+00 -5.2084251e+00 -5.5583585e+00 -8.5601348e+00 -9.2173592e+00 -7.7095246e+00 -6.4247195e+00 -2.9195376e+00 1.3696917e+00 2.3600111e-01 -3.5066462e+00 -1.7906518e+00 3.0267100e+00 4.4608049e+00 4.9647577e+00 8.1244909e+00 1.0462506e+01 9.6079485e+00 7.7730961e+00 5.8355237e+00 4.1832824e+00 4.4872281e+00 4.7070481e+00 1.1954062e+00 -3.3703080e+00 -4.2879123e+00 -3.7852632e+00 -5.9645982e+00 -8.4869057e+00 -7.4016607e+00 -4.3441103e+00 -2.3813524e+00 1.2418841e-01 4.9183614e+00 7.1076542e+00 1.3607427e+00 -7.3320053e+00 -8.9727762e+00 -3.2209033e+00 1.4899373e+00 1.0741419e+00 -1.4691569e+00 -2.5938840e+00 -1.2369807e+00 2.0206986e-01 -1.8303922e+00 -3.9449765e+00 1.4387487e+00 1.0514320e+01 1.0769771e+01
 8.8313817e+00 4.3005055e+00 -4.1649119e+00 -6.3050160e+00 -5.2402152e+00 -7.3721800e+00 -8.1775693e+00 -3.2534988e+00 1.7048012e+00 1.8813030e+00 1.0824107e-01 -1.1253794e+00 -2.4968623e+00 -3.3077789e+00 -2.1535871e+00 7.4321205e-01 4.6802272e+00 7.9643259e+00 7.9943665e+00 5.5547796e+00 4.3951321e+00 4.5254200e+00 2.3442211e+00 -1.8909218e+00 -3.5125831e+00 -7.2464997e-01 2.7212191e+00 2.5851414e+00 -9.2755899e-01 -3.8951814e+00 -3.6401440e+00 -1.7854451e+00 -1.5882577e+00 -3.5966400e+00 -5.5301748e+00 -5.3917715e+00 -3.4710664e+00 -1.6020516e+00 -7.3631744e-01 2.6970500e-01 2.6573457e+00 5.4863161e+00 6.9121613e+00 6.6655222e+00 5.6622659e+00 4.0389729e+00 9.3885229e-01 -3.9502750e+00 -8.8257786e+00 -1.0220073e+01 -6.5514972e+00 -7.9560635e-01 2.6491715e+00 3.0176599e+00 2.3249973e+00 1.3986930e+00 4.0408014e-01 6.3290633e-01 1.6628753e+00 6.5485073e-01 -1.8717202e+00 -1.4627624e+00 1.9782947e+00 3.2160739e+00 1.1668544e+00 -7.5422833e-02 -3.0476741e-01 -2.7414493e+00 -5.4076926e+00 -3.5109668e+00 1.5764495e+00 4.3840966e+00 3.4651353e+00 1.6677022e+00 1.3278134e+00 1.9641438e+00 9.7844787e-01 -2.6541428e+00 -5.4302555e+00 -3.6952895e+00 3.5658553e-01 1.7762362e+00 3.5450667e-02 -1.0828150e+00 8.1605611e-01 3.7404261e+00 4.2935454e+00 2.9825690e+00 3.2110963e+00 4.3252139e+00 2.6993864e+00 2.5772192e-01 1.2371109e+00 2.0607001e+00 -2.2704400e+00 -6.6867329e+00 -5.4038368e+00 -3.6397915e+00 -6.2586503e+00 -7.3385415e+00 -2.7550983e+00 7.9236928e-01 -1.8886836e+00 -5.6601482e+00 -3.8104737e+00 2.8583879e+00 7.6702934e+00 5.8872419e+00 9.0677176e-01 -1.9440434e-01 2.3735551e+00 2.3652435e+00 -7.5500799e-01 -1.8590439e+00 7.5920807e-03 1.8605444e+00 2.7519176e+00 2.3561563e+00 -2.1737359e-01 -2.8219683e+00 -2.2463695e+00 7.2443146e-01 3.6353362e+00 5.4375210e+00 4.7116456e+00 1.5334323e+00 1.3049015e-01 2.1877728e+00 2.5385513e+00 -1.5107798e+00 -4.8889180e+00 -4.1843992e+00 -2.2828085e+00 -1.0670605e+00 2.3457513e-01 2.0273180e-01 -2.0612892e+00 -3.3606344e+00 -2.1726779e+00 -1.3180010e+00 -1.4886559e+00 -6.8853732e-01 -3.2777472e-02 -1.2468097e+00 -2.0177334e+00 -9.4836544e-01 -4.9327480e-01 -9.0372213e-01 -6.2469066e-02 6.9582516e-01 -2.6679510e-01 -3.0107267e-01 1.5593932e+00 2.2971845e+00 2.3280989e+00 4.3614839e+00 5.9911319e+00 4.4196684e+00 2.4898740e+00 1.7785859e+00 -1.7747279e-03 -1.4677343e+00 -7.7654385e-02 6.3896630e-01 -1.8932167e+00 -3.7540125e+00 -3.6034108e+00 -4.3085200e+00 -4.2368712e+00 -1.2982768e+00 3.4464260e-01 -4.0509169e-01 1.7701181e+00 5.9147567e+00 5.4544044e+00 1.7826749e+00 4.6335736e-01 2.0463931e-01 -1.3535767e+00 -2.0307774e+00 -1.9379323e+00 -3.0905695e+00 -3.1283034e+00 -5.8490829e-01 9.5482502e-01 4.8349411e-01 5.4859920e-01 2.6505302e-01 -1.6738570e+00 -2.1912486e+00 3.2643425e-02 1.8745902e+00 1.8733346e+00 8.7274346e-01 -6.2320768e-01 -8.6521021e-01 9.8999512e-01 1.7587751e+00 3.6997317e-01 4.6666216e-01 1.9638847e+00 7.1586139e-01 -2.7192205e+00 -4.8546551e+00 -5.2275700e+00 -3.6331454e+00 -3.4432594e-01 8.2170170e-01 -7.7122599e-02 2.7567014e+00 7.0580169e+00 3.6661124e+00 -4.3602951e+00 -5.1712241e+00 9.4062577e-01 4.8370393e+00 4.8074790e+00 3.6350180e+00 1.7355182e+00 1.1764258e+00 3.3588501e+00 4.1348665e+00 1.5457105e+00 -8.1362250e-01 -2.4892348e+00 -4.6008297e+00 -3.5153619e+00 1.8112368e-01 -1.3466809e+00 -7.1410649e+00 -6.9291330e+00 -6.8888605e-01 2.1900116e+00 5.3854746e-01 -6.6370732e-01 -1.2650612e+00 -1.6732370e+00 2.4574404e-01 2.5040580e+00 1.8156371e+00 7.8117115e-01 1.9919812e+00 2.8459795e+00 2.4198319e+00 3.0987054e+00 4.2393728e+00 3.6648485e+00 2.1428796e+00 3.8022045e-01 -2.2021776e+00 -4.1744097e+00 -4.2930744e+00 -4.3848972e+00 -5.2515582e+00 -5.2594541e+00 -4.4249680e+00 -3.4217885e+00 -1.0180247e+00 1.8727737e+00 1.4909976e+00 -1.6255664e+00 -2.3798025e+00 6.6177734e-01 4.0583452e+00 5.4193601e+00 4.7630895e+00 2.7683942e+00 1.1101528e+00 1.2818523e+00 2.5446188e+00 3.6850506e+00 4.7988971e+00 5.2451330e+00 3.4546722e+00 3.2558037e-01 -1.3030521e+00 -1.3554915e+00 -2.6284306e+00 -5.3897891e+00 -6.1533489e+00 -3.3546173e+00 -1.5965785e-01 6.8257969e-01 5.0294837e-01 4.3335249e-01 -1.3020608e+00 -4.4203707e+00 -4.8678613e+00 -1.5345759e+00 1.3920361e+00 1.2277059e+00 -5.9079942e-02 -6.7115701e-01 -1.3347163e+00 -2.3535973e+00 -2.2881480e+00 2.0879504e-01 4.4173569e+00 7.1039609e+00 5.4811765e+00

On Thu, Jan 28, 2010 at 2:51 PM, Fernando Perez <fpe...@gm...> wrote:
> Thanks, with your and John's (off-list) approvals, it's committed.
> The patch that went in had more docs than what I posted here, but the
> code is identical.
Oops, somehow my commit had never made it, I just noticed now I was
trying to use it from another machine.
Fixed now, r8110.
Cheers,
f