2009/10/8 Charles R Harris :
> code generator problem and doesn't call for a jump in major version. We hope
> ;) I think David's hack, which looks to have been committed by Stefan,
> should fix things up.
I accidentally committed some of David's patches, but I reverted them
back out. I think Davi
On Wed, Oct 7, 2009 at 8:39 PM, Travis Oliphant wrote:
>
> On Oct 7, 2009, at 3:06 AM, David Cournapeau wrote:
>
> On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
> wrote:
>
>
>
> Looks like a clue ;)
>
>
> Ok, I fixed it here:
>
> http://github.com/cournape/numpy/tree/fix_abi
>
> But that's an
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 proble
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
On Wed, Oct 7, 2009 at 22:04, Alan G Isaac wrote:
> On 10/7/2009 10:51 PM, David Cournapeau wrote:
>> pimp-like strategies
>
>
> Which means ... ?
He meant "pimpl-like".
http://en.wikipedia.org/wiki/Opaque_pointer
--
Robert Kern
"I have come to believe that the whole world is an enigma, a har
On 10/7/2009 10:51 PM, David Cournapeau wrote:
> pimp-like strategies
Which means ... ?
Alan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Oct 7, 2009 at 21:55, David Cournapeau wrote:
> On Thu, Oct 8, 2009 at 11:51 AM, David Cournapeau 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 our structures and all to ma
On Thu, Oct 8, 2009 at 11:51 AM, David Cournapeau 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 our structures and all to make them more robust to those
> changes (using pimp-like strat
On Thu, Oct 8, 2009 at 11:39 AM, Travis Oliphant 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 was made under that
On Oct 7, 2009, at 3:06 AM, David Cournapeau wrote:
On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
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: inst
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 :
> I have seen that message, but I wasn't sure these errors were directly
> connecte
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\tC
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 remembe
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 np.
On Wed, Oct 7, 2009 at 7:07 AM, Charles R Harris
wrote:
>
>
> 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 wrote:
>>
>>> On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris
>>> wrote:
>>> >
>>> >
>>
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 wrote:
> On Wed, Oct 7, 2009 at 09:55,
On Wed, Oct 7, 2009 at 12:35, Gökhan Sever 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 to believe that
On Wed, Oct 7, 2009 at 12:21 PM, Christopher Barker
wrote:
> 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 :)
>
> Beca
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:
o.
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 B
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 wrote:
>
> On Oct 7, 2009, at 2:57 AM, Gökhan Sever wrote:
> > One more example. (I still think the behaviour of f
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], '>> x.tostring().encode('hex')
'80bf'
# This is a little-endian representation, in the order (real, imag)
# When I swap
On Wed, Oct 7, 2009 at 09:55, Gökhan Sever 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 to
> re-built mat
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 g
On Wed, Oct 7, 2009 at 6:59 AM, Charles R Harris
wrote:
>
>
> On Wed, Oct 7, 2009 at 6:37 AM, David Cournapeau wrote:
>
>> On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau
>> wrote:
>> >>
>> >> On Wed, Oct 7, 2009 at 2:31
On Wed, Oct 7, 2009 at 6:37 AM, David Cournapeau wrote:
> On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris
> wrote:
> >
> >
> > On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau
> wrote:
> >>
> >> On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
> >> wrote:
> >> >
> >> >
> >> > Looks like a clu
On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris
wrote:
>
>
> On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau wrote:
>>
>> On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
>> wrote:
>> >
>> >
>> > Looks like a clue ;)
>>
>> Ok, I fixed it here:
>>
>> http://github.com/cournape/numpy/tree/fix_ab
On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau wrote:
> On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
> 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
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 ".../.virtualenvs/default25/lib/python2.5/site-packages/n
On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
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 the API array of
fptr, we
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
[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 i
32 matches
Mail list logo
