Re: [Numpy-discussion] NumPy 1.8.0rc2 release
Hi,
I found an unexpected difference from numpy 1.7.1 and 1.8.0rc2 with Python
3.3.2 on Ubuntu 12.04 (amd64). Here is the test program:
import numpy as np
print(np.__version__)
K = np.array([[ 0., 0., 0., 0.],
[-0., 0., 0., 0.],
[ 0., -0., 0., 0.],
[ 0., -0., 0., 0.]])
w, V = np.linalg.eigh(K)
print('w')
print(w)
with numpy 1.7.1:
1.7.1
w
[-0. -0. -0. 0.]
with numpy 1.8.0rc2:
1.8.0rc2
w
[ 0. 0. 0. 0.]
Apologies if this is my mistake!
-Andrew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.8.0rc2 release
On Fri, Oct 25, 2013 at 9:07 AM, Andrew Straw
wrote:
>
> Hi,
>
> I found an unexpected difference from numpy 1.7.1 and 1.8.0rc2 with
Python 3.3.2 on Ubuntu 12.04 (amd64). Here is the test program:
>
> import numpy as np
> print(np.__version__)
> K = np.array([[ 0., 0., 0., 0.],
> [-0., 0., 0., 0.],
> [ 0., -0., 0., 0.],
> [ 0., -0., 0., 0.]])
> w, V = np.linalg.eigh(K)
> print('w')
> print(w)
>
> with numpy 1.7.1:
>
> 1.7.1
> w
> [-0. -0. -0. 0.]
>
> with numpy 1.8.0rc2:
>
> 1.8.0rc2
> w
> [ 0. 0. 0. 0.]
>
> Apologies if this is my mistake!
> -Andrew
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
My first reaction was to think that eigh would not have guarantees because
the matrix is not hermitian, but now I see that eigh deliberately uses the
upper vs. lower part according to the UPLO arg which is documented as
defaulting to 'L', so I see why this difference between numpy versions is
an unexpected problem.
Alex
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: SciPy 0.13.0 release
Hi, On Sat, Oct 19, 2013 at 2:40 PM, Ralf Gommers wrote: > On behalf of the SciPy development team I'm pleased to announce the > availability of SciPy 0.13.0. This release contains some interesting new > features (see highlights below) and half a year's worth of maintenance work. > 65 people contributed to this release. > > Some of the highlights are: > > - support for fancy indexing and boolean comparisons with sparse matrices > - interpolative decompositions and matrix functions in the linalg module > - two new trust-region solvers for unconstrained minimization > > This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or greater. > Support for Python 2.4 and 2.5 has been dropped as of this release. > > Sources and binaries can be found at > http://sourceforge.net/projects/scipy/files/scipy/0.13.0/, release notes are > copied below. Sorry to be slow to the party, but I just wanted to point out: git shortlog -ns v0.12.0..v0.13.0 389 Pauli Virtanen 225 Ralf Gommers 105 alex 104 Blake Griffith 101 Warren Weckesser ... So - to y'all, but in particular to Pauli and Ralf - thank you for this all this great, patient, organized work. A deep bow, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.8.0rc2 release
On Fri, Oct 25, 2013 at 7:07 AM, Andrew Straw wrote:
> Hi,
>
> I found an unexpected difference from numpy 1.7.1 and 1.8.0rc2 with Python
> 3.3.2 on Ubuntu 12.04 (amd64). Here is the test program:
>
> import numpy as np
> print(np.__version__)
> K = np.array([[ 0., 0., 0., 0.],
> [-0., 0., 0., 0.],
> [ 0., -0., 0., 0.],
> [ 0., -0., 0., 0.]])
> w, V = np.linalg.eigh(K)
> print('w')
> print(w)
>
> with numpy 1.7.1:
>
> 1.7.1
> w
> [-0. -0. -0. 0.]
>
> with numpy 1.8.0rc2:
>
> 1.8.0rc2
> w
> [ 0. 0. 0. 0.]
>
This appears to have gotten fixed since rc2:
In [1]: K = np.array([[ 0., 0., 0., 0.],
[-0., 0., 0., 0.],
[ 0., -0., 0., 0.],
[ 0., -0., 0., 0.]])
In [2]: eigh(K)
Out[2]:
(array([-0., -0., -0., 0.]),
array([[-0.78251031, 0.37104402, 0.00198815, 0.5 ],
[-0.29974269, 0.03728557, 0.81164285, -0.5 ],
[ 0.54246491, 0.46764373, 0.48686874, 0.5 ],
[-0.05969728, -0.80140218, 0.32278596, 0.5 ]]))
In [3]: np.__version__
Out[3]: '1.8.0.dev-ced0a94'
Could you try the current 1.8.x version on github and see if the problem
persists?
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.8.0rc2 release
It's py3 only, see the discussion in #3977.
On 25 Oct 2013 17:45, "Charles R Harris" wrote:
>
>
>
> On Fri, Oct 25, 2013 at 7:07 AM, Andrew Straw
> wrote:
>
>> Hi,
>>
>> I found an unexpected difference from numpy 1.7.1 and 1.8.0rc2 with
>> Python 3.3.2 on Ubuntu 12.04 (amd64). Here is the test program:
>>
>> import numpy as np
>> print(np.__version__)
>> K = np.array([[ 0., 0., 0., 0.],
>> [-0., 0., 0., 0.],
>> [ 0., -0., 0., 0.],
>> [ 0., -0., 0., 0.]])
>> w, V = np.linalg.eigh(K)
>> print('w')
>> print(w)
>>
>> with numpy 1.7.1:
>>
>> 1.7.1
>> w
>> [-0. -0. -0. 0.]
>>
>> with numpy 1.8.0rc2:
>>
>> 1.8.0rc2
>> w
>> [ 0. 0. 0. 0.]
>>
>
> This appears to have gotten fixed since rc2:
>
> In [1]: K = np.array([[ 0., 0., 0., 0.],
> [-0., 0., 0., 0.],
> [ 0., -0., 0., 0.],
> [ 0., -0., 0., 0.]])
>
> In [2]: eigh(K)
> Out[2]:
> (array([-0., -0., -0., 0.]),
> array([[-0.78251031, 0.37104402, 0.00198815, 0.5 ],
>[-0.29974269, 0.03728557, 0.81164285, -0.5 ],
>[ 0.54246491, 0.46764373, 0.48686874, 0.5 ],
>[-0.05969728, -0.80140218, 0.32278596, 0.5 ]]))
>
> In [3]: np.__version__
> Out[3]: '1.8.0.dev-ced0a94'
>
> Could you try the current 1.8.x version on github and see if the problem
> persists?
>
> Chuck
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.8.0rc2 release
Yeah, sorry for the confusion. I thought my email didn't go through. I
created a bug report on github instead. Now I find the email was indeed
sent. Sorry about that. Looking at the github activity (see
https://github.com/numpy/numpy/issues/3977 ), I think a fix is almost at
hand thanks to Julian Taylor.
Best,
Andrew
On Fri, Oct 25, 2013 at 7:52 PM, Nathaniel Smith wrote:
> It's py3 only, see the discussion in #3977.
> On 25 Oct 2013 17:45, "Charles R Harris"
> wrote:
>
>>
>>
>>
>> On Fri, Oct 25, 2013 at 7:07 AM, Andrew Straw
>> wrote:
>>
>>> Hi,
>>>
>>> I found an unexpected difference from numpy 1.7.1 and 1.8.0rc2 with
>>> Python 3.3.2 on Ubuntu 12.04 (amd64). Here is the test program:
>>>
>>> import numpy as np
>>> print(np.__version__)
>>> K = np.array([[ 0., 0., 0., 0.],
>>> [-0., 0., 0., 0.],
>>> [ 0., -0., 0., 0.],
>>> [ 0., -0., 0., 0.]])
>>> w, V = np.linalg.eigh(K)
>>> print('w')
>>> print(w)
>>>
>>> with numpy 1.7.1:
>>>
>>> 1.7.1
>>> w
>>> [-0. -0. -0. 0.]
>>>
>>> with numpy 1.8.0rc2:
>>>
>>> 1.8.0rc2
>>> w
>>> [ 0. 0. 0. 0.]
>>>
>>
>> This appears to have gotten fixed since rc2:
>>
>> In [1]: K = np.array([[ 0., 0., 0., 0.
>> ],
>> [-0., 0., 0., 0.],
>> [ 0., -0., 0., 0.],
>> [ 0., -0., 0., 0.]])
>>
>> In [2]: eigh(K)
>> Out[2]:
>> (array([-0., -0., -0., 0.]),
>> array([[-0.78251031, 0.37104402, 0.00198815, 0.5 ],
>>[-0.29974269, 0.03728557, 0.81164285, -0.5 ],
>>[ 0.54246491, 0.46764373, 0.48686874, 0.5 ],
>>[-0.05969728, -0.80140218, 0.32278596, 0.5 ]]))
>>
>> In [3]: np.__version__
>> Out[3]: '1.8.0.dev-ced0a94'
>>
>> Could you try the current 1.8.x version on github and see if the problem
>> persists?
>>
>> Chuck
>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] vectorizing recursive sequences
I recently came up with a way of vectorizing some recursive sequence calculations. While it works, I am afraid it is relying on implementation details potentially subject to change. The basic idea is illustrated by this function, calculating the first n items of the Fibonacci sequence: def fibonacci(n): fib = np.empty(n, dtype=np.intp) fib[:2] = 1 np.add(fib[:-2], fib[1:-1], out=fib[2:]) return fib >>> fibonacci(10) array([ 1, 1, 2, 3, 5, 8, 13, 21, 34, 55], dtype=int64) I believe that the biggest issue that could break this is if the ufunc decided to buffer the arrays, as this is relying on the inputs and outputs of np.add sharing the same memory. You can use the same idea to do more complicated things, for instance to calculate the items of the sequence: f[0] = a[0] f[n] = a[n] + x * f[n-1] from numpy.lib.stride_tricks import as_strided from numpy.core.umath_tests import inner1d def f(a, x): out = np.array(a, copy=True, dtype=np.double) n = len(a) out_view = as_strided(out, shape=(n-1, 2), strides=out.strides*2) inner1d(out_view, [x, 1], out=out[1:]) return out >>> f(np.arange(10), 0.1) array([ 0., 1., 2.1 , 3.21 , 4.321 , 5.4321, 6.54321 , 7.654321 , 8.7654321 , 9.87654321]) Again, I think buffering is the clearest danger of doing something like this, as the first input and output must share the same memory for this to work. That this is a real concern is easy to see: since `inner1d` only has loops registered for long ints and double floats: >>> inner1d.types ['ll->l', 'dd->d'] the above function `f` doesn't work if the `out` array is created, e.g. as np.float32, since there will be buffering happening because of the type casting. So I have two questions: 1. Is there some other reason, aside from buffering, that could go wrong, or change in a future release? 2. As far as buffering is concerned, I thought of calling `np.setbuffer(1)` before any of these functions, but it complains and requests that the value be a multiple of 16. Is there any other way to ensure that the data is fetched from an updated array in every internal iteration? Thanks! Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] vectorizing recursive sequences
"Jaime Fernández del Río" a écrit : >I recently came up with a way of vectorizing some recursive sequence >calculations. While it works, I am afraid it is relying on >implementation >details potentially subject to change. The basic idea is illustrated by >this function, calculating the first n items of the Fibonacci sequence: > >def fibonacci(n): > >fib = np.empty(n, dtype=np.intp) > >fib[:2] = 1 > >np.add(fib[:-2], fib[1:-1], out=fib[2:]) > >return fib > > fibonacci(10) > >array([ 1, 1, 2, 3, 5, 8, 13, 21, 34, 55], dtype=int64) > > >I believe that the biggest issue that could break this is if the ufunc >decided to buffer the arrays, as this is relying on the inputs and >outputs >of np.add sharing the same memory. > > >You can use the same idea to do more complicated things, for instance >to >calculate the items of the sequence: > > >f[0] = a[0] > >f[n] = a[n] + x * f[n-1] > > >from numpy.lib.stride_tricks import as_strided > >from numpy.core.umath_tests import inner1d > > >def f(a, x): > >out = np.array(a, copy=True, dtype=np.double) > >n = len(a) > >out_view = as_strided(out, shape=(n-1, 2), strides=out.strides*2) > >inner1d(out_view, [x, 1], out=out[1:]) > >return out > > f(np.arange(10), 0.1) > >array([ 0., 1., 2.1 , 3.21 , 4.321 , > > 5.4321, 6.54321 , 7.654321 , 8.7654321 , 9.87654321]) > >Again, I think buffering is the clearest danger of doing something >like >this, as the first input and output must share the same memory for this >to >work. That this is a real concern is easy to see: since `inner1d` only >has >loops registered for long ints and double floats: > inner1d.types >['ll->l', 'dd->d'] > >the above function `f` doesn't work if the `out` array is created, e.g. >as >np.float32, since there will be buffering happening because of the type >casting. > >So I have two questions: > >1. Is there some other reason, aside from buffering, that could go >wrong, >or change in a future release? >2. As far as buffering is concerned, I thought of calling >`np.setbuffer(1)` >before any of these functions, but it complains and requests that the >value >be a multiple of 16. Is there any other way to ensure that the data is >fetched from an updated array in every internal iteration? > >Thanks! > >Jaime > >-- >(\__/) >( O.o) >( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus >planes >de dominación mundial. > > > > >___ >NumPy-Discussion mailing list >NumPy-Discussion@scipy.org >http://mail.scipy.org/mailman/listinfo/numpy-discussion Hi, If you're recursive computation is always linear, like Fibonacci, your usecase falls in the scope of scipy.signal.lfilter which is compiled code based. For your last example, I think parameters would be : numerator b = [1] and denominator a=[1 -x] (can't check the code on my cell phone sorry) best, Pierre -- Pierre Haessig___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Pythonmac-SIG] Building extension modules with Xcode 5
Ned, I think this fell off the list (I really don't like when reply is not set to the list...) On Fri, Oct 25, 2013 at 4:33 PM, Ned Deily wrote: > > On Oct 25, 2013, at 15:17 , Chris Barker wrote: > > > On Thu, Oct 24, 2013 at 7:29 PM, Ned Deily wrote: > > I'm really confused here. Using the current 2.7.5 64-bit installer > (from > > May) on 10.8.5 with Xcode 5.0.1 works just fine for me. > > > > I'm not on 10.8 or XCode5, but does it make a difference whether you > installed XCode 5 after Xcode 4? i.e. someone may have gcc4.2 around form > XCode 4, but not if they installed XCode 5 on a raw machine. > > Not that I know of. gcc-4.2 is a red herring as far as I can tell. > Distutils has known how to deal with a missing compiler for a couple of > releases now. Good to know -- I know I really need to move forward -- I wonder if there is an XCode5 for 10.6? pProbably not -- but for some screwy reason Apple does not provide a free XCode4 for 10.6, either (though you can hack the installer for 10.7 ... > However, I did just realize that I had forgotten about a problem when > using the current 32-bit-only installers with Xcode 5. I've just posted > about that; it's described now in http://bugs.python.org/issue19400 > > Good to fix that, but does anyone need it anymore? Though I use it when I need to force 32 bit, even on a 64 bit system (I'm working with some not-64-bit safe C++ code...) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Pythonmac-SIG] Building extension modules with Xcode 5
Oops! Wrong list--darn auto complete! Sorry about that, Chris On Oct 25, 2013, at 5:08 PM, Chris Barker wrote: Ned, I think this fell off the list (I really don't like when reply is not set to the list...) On Fri, Oct 25, 2013 at 4:33 PM, Ned Deily wrote: > > On Oct 25, 2013, at 15:17 , Chris Barker wrote: > > > On Thu, Oct 24, 2013 at 7:29 PM, Ned Deily wrote: > > I'm really confused here. Using the current 2.7.5 64-bit installer > (from > > May) on 10.8.5 with Xcode 5.0.1 works just fine for me. > > > > I'm not on 10.8 or XCode5, but does it make a difference whether you > installed XCode 5 after Xcode 4? i.e. someone may have gcc4.2 around form > XCode 4, but not if they installed XCode 5 on a raw machine. > > Not that I know of. gcc-4.2 is a red herring as far as I can tell. > Distutils has known how to deal with a missing compiler for a couple of > releases now. Good to know -- I know I really need to move forward -- I wonder if there is an XCode5 for 10.6? pProbably not -- but for some screwy reason Apple does not provide a free XCode4 for 10.6, either (though you can hack the installer for 10.7 ... > However, I did just realize that I had forgotten about a problem when > using the current 32-bit-only installers with Xcode 5. I've just posted > about that; it's described now in http://bugs.python.org/issue19400 > > Good to fix that, but does anyone need it anymore? Though I use it when I need to force 32 bit, even on a 64 bit system (I'm working with some not-64-bit safe C++ code...) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
