[Numpy-discussion] assert_allclose equal_nan default value.

[Charles R Harris]

Hi All,

Just a heads up that there is a PR changing the default value of
`equal_nan` to `True` in the `assert_allclose` test function. The
`equal_nan` argument was previously ineffective due to a bug that has
recently been fixed. The current default value of `False` is not backward
compatible and causes test failures in  scipy. See the extended argument at
https://github.com/numpy/numpy/pull/8184. I think this change is the right
thing to do but want to make sure everyone is aware of it.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] assert_allclose equal_nan default value.

[Nathan Goldbaum]

Agreed, especially given the prevalence of using this function in
downstream test suites:

https://github.com/search?utf8=%E2%9C%93&q=numpy+assert_allclose&type=Code&ref=searchresults

On Thu, Oct 20, 2016 at 12:16 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:

> Hi All,
>
> Just a heads up that there is a PR changing the default value of
> `equal_nan` to `True` in the `assert_allclose` test function. The
> `equal_nan` argument was previously ineffective due to a bug that has
> recently been fixed. The current default value of `False` is not backward
> compatible and causes test failures in  scipy. See the extended argument at
> https://github.com/numpy/numpy/pull/8184. I think this change is the
> right thing to do but want to make sure everyone is aware of it.
>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] assert_allclose equal_nan default value.

[Benjamin Root]

+1. I was almost always setting it to True anyway.

On Thu, Oct 20, 2016 at 1:18 PM, Nathan Goldbaum 
wrote:

> Agreed, especially given the prevalence of using this function in
> downstream test suites:
>
> https://github.com/search?utf8=%E2%9C%93&q=numpy+assert_
> allclose&type=Code&ref=searchresults
>
> On Thu, Oct 20, 2016 at 12:16 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> Hi All,
>>
>> Just a heads up that there is a PR changing the default value of
>> `equal_nan` to `True` in the `assert_allclose` test function. The
>> `equal_nan` argument was previously ineffective due to a bug that has
>> recently been fixed. The current default value of `False` is not backward
>> compatible and causes test failures in  scipy. See the extended argument at
>> https://github.com/numpy/numpy/pull/8184. I think this change is the
>> right thing to do but want to make sure everyone is aware of it.
>>
>> Chuck
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] assert_allclose equal_nan default value.

[Marten van Kerkwijk]

Good, that means I can revert some changes to astropy, which made the
tests less readable.
-- Marten
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] invalid value treatment, in filter_design

[R Schumacher]

In an attempt to computationally invert the effect of an analog RC 
filter on a data set and reconstruct the "true" signal, a co-worker 
suggested: "Mathematically, you just reverse the a and b parameters. 
Then the zeros become the poles, but if the new poles are not inside 
the unit circle, the filter is not stable."


So, to "stabilize" the poles' issue seen, I test for the DIV/0 error 
and set it to 2./N+0.j in scipy/signal/filter_design.py ~ line 244

d = polyval(a[::-1], zm1)
if d[0]==0.0+0.j:
d[0] = 2./N+0.j
h = polyval(b[::-1], zm1) / d

- Question is, is this a mathematically valid treatment?
- Is there a better way to invert a Butterworth filter, or work with 
the DIV/0 that occurs without modifying the signal library?

- Should I post to *-users instead?

I noted d[0] > 2./N+0.j makes the zero bin result spike low; 2/N 
gives a reasonable "extension" of the response curve. This whole 
tweak causes a zero offset however, which I remove.


An example attached...


Ray Schumacher
Programmer/Consultant
import numpy as np
from scipy.signal import butter, lfilter, freqz
import matplotlib.pyplot as plt


def butter_highpass(cutoff, fs, order=5):
nyq = 0.5 * fs
normal_cutoff = cutoff / nyq
b, a = butter(order, Wn=normal_cutoff, btype='highpass', analog=False)
return b, a

def butter_inv_highpass(cutoff, fs, order=5):
nyq = 0.5 * fs
normal_cutoff = cutoff / nyq
b, a = butter(order, Wn=normal_cutoff, btype='highpass', analog=False)
## swap the components
return a, b

def butter_highpass_filter(data, cutoff, fs, order=5):
b, a = butter_highpass(cutoff, fs, order=order)
y = lfilter(b, a, data)
return y

def butter_inv_highpass_filter(data, cutoff, fs, order=5):
b, a = butter_inv_highpass(cutoff, fs, order=1)
offset = data.mean()
y = lfilter(b, a, data)
## remove new offset
y -= (y.mean() - offset)
return y


# Filter requirements.
order = 1
fs = 1024.0   # sample rate, Hz
cutoff = 11.6  # desired cutoff frequency of the filter, Hz
nyquist = fs/2.

# Get the filter coefficients so we can check its frequency response.
b, a = butter_highpass(cutoff, fs, order)
bi, ai = butter_inv_highpass(cutoff, fs, order)


# Plot the frequency response.
plt.subplot(2, 1, 1)
w, h = freqz(b, a, worN=8000)
plt.plot(0.5*fs*w/np.pi, np.abs(h), 'g', label='high pass resp')
wi, hi = freqz(bi, ai, worN=8000)
plt.plot(0.5*fs*wi/np.pi, np.abs(hi), 'r', label='inv. high pass resp')
plt.plot(cutoff, 0.5*np.sqrt(2), 'ko')
plt.axvline(cutoff, color='k')
plt.xlim(0, 0.05*fs)
plt.ylim(0, 5)
plt.title("Lowpass Filter Frequency Response")
plt.xlabel('Frequency [Hz]')
# add the legend in the middle of the plot
leg = plt.legend(fancybox=True)
# set the alpha value of the legend: it will be translucent
leg.get_frame().set_alpha(0.5)
plt.subplots_adjust(hspace=0.35)
plt.grid()


# Demonstrate the use of the filter.
# First make some data to be filtered.
T = 5.0 # seconds
n = int(T * fs) # total number of samples
t = np.linspace(0, T, n, endpoint=False)
# "Noisy" data.  We want to recover the 1.2 Hz signal from this.
data = np.sin(1.2*2*np.pi*t)# + 1.5*np.cos(9*2*np.pi*t) + 
0.5*np.sin(12.0*2*np.pi*t)

# Filter the data, and plot both the original and filtered signals.
y = butter_highpass_filter(data, cutoff, fs, order)
yi = butter_inv_highpass_filter(y, cutoff, fs, order)

plt.subplot(2, 1, 2)
plt.plot(t, data, 'b-', label='1.2Hz "real" data')
plt.plot(t, y, 'g-', linewidth=2, label='blue box data')
plt.plot(t, yi, 'r--', linewidth=2, label='round-trip data')
plt.xlabel('Time [sec]')
plt.grid()
#plt.legend()
# add the legend in the middle of the plot
leg = plt.legend(fancybox=True)
# set the alpha value of the legend: it will be translucent
leg.get_frame().set_alpha(0.5)
plt.subplots_adjust(hspace=0.35)
plt.show()___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] fpower ufunc

[Charles R Harris]

Hi All,

I've put up a preliminary PR  for
the proposed fpower ufunc. Apart from adding more tests and documentation,
I'd like to settle a few other things. The first is the name, two names
have been proposed and we should settle on one

   - fpower (short)
   - float_power (obvious)

The second thing is the minimum precision. In the preliminary version I
have used float32, but perhaps it makes more sense for the intended use to
make the minimum precision float64 instead.

Thoughts?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] fpower ufunc

[Nathaniel Smith]

On Thu, Oct 20, 2016 at 7:58 PM, Charles R Harris
 wrote:
> Hi All,
>
> I've put up a preliminary PR for the proposed fpower ufunc. Apart from
> adding more tests and documentation, I'd like to settle a few other things.
> The first is the name, two names have been proposed and we should settle on
> one
>
> fpower (short)
> float_power (obvious)

+0.6 for float_power

> The second thing is the minimum precision. In the preliminary version I have
> used float32, but perhaps it makes more sense for the intended use to make
> the minimum precision float64 instead.

Can you elaborate on what you're thinking? I guess this is because
float32 has limited range compared to float64, so is more likely to
see overflow? float32 still goes up to 10**38 which is < int64_max**2,
FWIW. Or maybe there's some subtlety with the int->float casting here?

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] fpower ufunc

[Charles R Harris]

On Thu, Oct 20, 2016 at 9:11 PM, Nathaniel Smith  wrote:

> On Thu, Oct 20, 2016 at 7:58 PM, Charles R Harris
>  wrote:
> > Hi All,
> >
> > I've put up a preliminary PR for the proposed fpower ufunc. Apart from
> > adding more tests and documentation, I'd like to settle a few other
> things.
> > The first is the name, two names have been proposed and we should settle
> on
> > one
> >
> > fpower (short)
> > float_power (obvious)
>
> +0.6 for float_power
>
> > The second thing is the minimum precision. In the preliminary version I
> have
> > used float32, but perhaps it makes more sense for the intended use to
> make
> > the minimum precision float64 instead.
>
> Can you elaborate on what you're thinking? I guess this is because
> float32 has limited range compared to float64, so is more likely to
> see overflow? float32 still goes up to 10**38 which is < int64_max**2,
> FWIW. Or maybe there's some subtlety with the int->float casting here?
>

logical, (u)int8, (u)int16, and float16 get converted to float32, which is
probably sufficient to avoid overflow and such. My thought was that float32
is something of a "specialized" type these days, while float64 is the
standard floating point precision for everyday computation.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion