matplotlib-devel Mailing List for matplotlib

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.