On Wed, Oct 7, 2009 at 12:47 AM, Pierre GM pgmdevl...@gmail.com wrote:
On Oct 7, 2009, at 1:12 AM, Gökhan Sever wrote:
One more from me:
I[1]: a = np.arange(5)
I[2]: mask = 999
I[6]: a[3] = 999
I[7]: am = ma.masked_equal(a, mask)
I[8]: am
O[8]:
masked_array(data = [0 1 2 --
[I am resending this as the previous attempt seems to have failed]
Hello List,
I am looking at memory errors when using numpy.linalg.eig().
Short version:
I had memory errors in numpy.linalg.eig(), and I have reasons (valgrind)
to believe these are due to writing to incorrect memory addresses
On Oct 7, 2009, at 2:57 AM, Gökhan Sever wrote:
One more example. (I still think the behaviour of fill_value is
inconsistent)
Well, ma.masked_values use `value` to define fill_value,
ma.masked_equal does not. So yes, there's an inconsistency here. Once
again, please fill an enhancement
On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
Looks like a clue ;)
Ok, I fixed it here:
http://github.com/cournape/numpy/tree/fix_abi
But that's an ugly hack. I think we should consider rewriting how we
generate the API: instead of automatically growing
All,
I need to test the numpy SVN on a 10.6.1 mac, but using Python 2.5.4
(32b) instead of the 2.6.1 (64b).
The sources get compiled OK (apparently, find the build here:
http://pastebin.com/m147a2909
) but numpy fails to import:
File
On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau courn...@gmail.com wrote:
On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
Looks like a clue ;)
Ok, I fixed it here:
http://github.com/cournape/numpy/tree/fix_abi
But that's an ugly hack. I think we
On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau courn...@gmail.com wrote:
On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
Looks like a clue ;)
Ok, I fixed it here:
On Wed, Oct 7, 2009 at 6:37 AM, David Cournapeau courn...@gmail.com wrote:
On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau courn...@gmail.com
wrote:
On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
On Wed, Oct 7, 2009 at 6:59 AM, Charles R Harris
charlesr.har...@gmail.comwrote:
On Wed, Oct 7, 2009 at 6:37 AM, David Cournapeau courn...@gmail.comwrote:
On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau
Hello,
I checked-out the latest trunk and make a new installation of NumPy. My
question: Is it a known behaviour that this action will result with
re-building other packages that are dependent on NumPy. In my case, I had to
re-built matplotlib, and now scipy.
Here is the error message that I am
On Wed, Oct 7, 2009 at 09:55, Gökhan Sever gokhanse...@gmail.com wrote:
Hello,
I checked-out the latest trunk and make a new installation of NumPy. My
question: Is it a known behaviour that this action will result with
re-building other packages that are dependent on NumPy. In my case, I had
I'm noticing an inconsistency as to how complex numbers are byteswapped
as arrays vs. scalars, and wondering if I'm doing something wrong.
x = np.array([-1j], 'c8')
x.tostring().encode('hex')
'80bf'
# This is a little-endian representation, in the order (real, imag)
# When I
Added as comment in the same entry:
http://projects.scipy.org/numpy/ticket/1253#comment:1
Guessing that this one should be easy to fix :)
On Wed, Oct 7, 2009 at 3:05 AM, Pierre GM pgmdevl...@gmail.com wrote:
On Oct 7, 2009, at 2:57 AM, Gökhan Sever wrote:
One more example. (I still think
josef.p...@gmail.com wrote:
I wanted to avoid the python loop and thought creating the view will be faster
with large arrays. But for this I need to know the memory length of a
row of arbitrary types for the conversion to strings,
ndarray.itemsize
might do it.
-Chris
--
Christopher
Gökhan Sever wrote:
Sorry too much time spent in ipython -pylab :)
Good reflex. Saves you from making extra explanations. But it works with
just typing array why should I type np.array (Ohh my namespacess :)
Because it shouldn't work that way! I use -pylab, but I've added:
On Wed, Oct 7, 2009 at 12:21 PM, Christopher Barker
chris.bar...@noaa.govwrote:
Gökhan Sever wrote:
Sorry too much time spent in ipython -pylab :)
Good reflex. Saves you from making extra explanations. But it works with
just typing array why should I type np.array (Ohh my
On Wed, Oct 7, 2009 at 12:35, Gökhan Sever gokhanse...@gmail.com wrote:
Do you know what shortcut name is used for scipy package itself?
I do not recommend using import scipy or import scipy as
Import the subpackages directly (e.g. from scipy import linalg).
--
Robert Kern
I have come
I have seen that message, but I wasn't sure these errors were directly
connected since he mentions of getting segfaults whereas in my case only
gives import errors. Building a new copy of scipy fixed this error.
On Wed, Oct 7, 2009 at 10:10 AM, Robert Kern robert.k...@gmail.com wrote:
On Wed,
On Wed, Oct 7, 2009 at 7:07 AM, Charles R Harris
charlesr.har...@gmail.comwrote:
On Wed, Oct 7, 2009 at 6:59 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Wed, Oct 7, 2009 at 6:37 AM, David Cournapeau courn...@gmail.comwrote:
On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris
Pierre GM wrote:
On Oct 6, 2009, at 10:08 PM, Bruce Southey wrote:
option to merge delimiters - actually in SAS it is default
Wow! that sure strikes me as a bad choice.
Ahah! I get it. Well, I remember that we discussed something like that a
few months ago when I started working on
On 10/07/2009 02:14 PM, Christopher Barker wrote:
Pierre GM wrote:
On Oct 6, 2009, at 10:08 PM, Bruce Southey wrote:
option to merge delimiters - actually in SAS it is default
Wow! that sure strikes me as a bad choice.
Ahah! I get it. Well, I remember that we
On Oct 7, 2009, at 3:54 PM, Bruce Southey wrote:
Anyhow, I do like what genfromtxt is doing so merging multiple
delimiters of the same type is not really needed.
Thinking about it, merging multiple delimiters of the same type can be
tricky: how do you distinguish between, say,
AAA\t\tCCC
You can pull the patches from David's fix_abi branch:
http://github.com/cournape/numpy/tree/fix_abi
This branch has been hacked to be ABI compatible with previous versions.
Cheers
Stéfan
2009/10/7 Gökhan Sever gokhanse...@gmail.com:
I have seen that message, but I wasn't sure these errors
On Oct 7, 2009, at 3:06 AM, David Cournapeau wrote:
On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
Looks like a clue ;)
Ok, I fixed it here:
http://github.com/cournape/numpy/tree/fix_abi
But that's an ugly hack. I think we should consider rewriting how
On Thu, Oct 8, 2009 at 11:39 AM, Travis Oliphant oliph...@enthought.com wrote:
I apologize for the mis communication that has occurred here.
No problem
I did not
understand that there was a desire to keep ABI compatibility with NumPy 1.3
when NumPy 1.4 was released. The datetime merge
On Wed, Oct 7, 2009 at 21:55, David Cournapeau courn...@gmail.com wrote:
On Thu, Oct 8, 2009 at 11:51 AM, David Cournapeau courn...@gmail.com wrote:
I would prefer passing to numpy 2.0 when we really need to break ABI
and API - at that point, I think we should also think hard about
changing
On 10/7/2009 10:57 PM, Robert Kern wrote:
it's pimpl
OK: http://en.wikipedia.org/wiki/Opaque_pointer
Thanks,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Alan G Isaac wrote:
On 10/7/2009 10:51 PM, David Cournapeau wrote:
pimp-like strategies
Which means ... ?
The idea is to put one pointer in you struct instead of all members - it
is a form of encapsulation, and it is enforced at compile time. I think
part of the problem with
On Wed, Oct 7, 2009 at 8:39 PM, Travis Oliphant oliph...@enthought.comwrote:
On Oct 7, 2009, at 3:06 AM, David Cournapeau wrote:
On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
Looks like a clue ;)
Ok, I fixed it here:
29 matches
Mail list logo
