On 1/12/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
>
>
> On 1/12/07, Torgil Svensson <[EMAIL PROTECTED]> wrote:
> > On 1/12/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
> > [CHOP]
> >
> > > the core. I'm sure it's less efficient, but you shouldn't need to parse
> the
> > > data structure in
On 1/13/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
>
> On 1/12/07, David Cournapeau <[EMAIL PROTECTED]> wrote:
> > On 1/13/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
> > > I think it may have all been cleared up now, but just in case:
> > >
> >
> > > but how do you get single strided?
On 1/12/07, David Cournapeau <[EMAIL PROTECTED]> wrote:
On 1/13/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
> I think it may have all been cleared up now, but just in case:
>
> but how do you get single strided? this is what always made it hard for
> me to know how to write this kind of c
On 1/13/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
> I think it may have all been cleared up now, but just in case:
>
> >>> a
> array([[[ 0, 1, 2, 3],
> [ 4, 5, 6, 7],
> [ 8, 9, 10, 11]],
>
> [[12, 13, 14, 15],
> [16, 17, 18, 19],
> [20, 21
Christopher Barker wrote:
>>Now, it is exposed in the concept of an array iterator. Anybody
>>can take advantage of it as it there is a C-API call to get an array
>>iterator from the array
>>
>>
>
>Is this iterator as efficient as incrementing the index for contiguous
>arrays? i.e. is ther
I think it may have all been cleared up now, but just in case:
>>> a
array([[[ 0, 1, 2, 3],
[ 4, 5, 6, 7],
[ 8, 9, 10, 11]],
[[12, 13, 14, 15],
[16, 17, 18, 19],
[20, 21, 22, 23]]])
>>> a.flags
C_CONTIGUOUS : True
F_CONTIGUOUS : False
>
> I'm concerned about the direction that this PEP seems to be going. The
> original proposal was borderline too complicated IMO, and now it seems
> headed in the direction of more complexity.
Well at least people are talking about what they would like to see.
But, I think we should reign i
Christopher Barker wrote:
>Gael Varoquaux wrote:
>
>
>>Yes, indeed. I was just wondering if the PEP could be used for a
>>performant implementation of trees.
>>
>>
>
>That would be a whole new PEP, and one we're not the least bit ready for.
>
>
>
>>Basicaly that is mapping a tree to an
>>a
Gael Varoquaux wrote:
> Yes, indeed. I was just wondering if the PEP could be used for a
> performant implementation of trees.
That would be a whole new PEP, and one we're not the least bit ready for.
> Basicaly that is mapping a tree to an
> array, which is possible.
Possible, but probably not
Travis Oliphant ieee.org> writes:
>
> Adam Jenkins wrote:
> > I just tried it, and it does solve the problem for the
> > mathematical operators like + and -, but doesn't seem to work for
> > the comparison operators. That is, if I write
> >
> > lhs < rhs
> >
> > where lhs is a numpy.ndarray
Adam Jenkins wrote:
> Timothy Hochberg ieee.org> writes:
>
>>You want __array_priority__; add an attribute __array_priority__ to your
>
> array-like object and set it's value to, say, 10 and ndarrays will defer to
> your
> object.
>
> Thank you very much. I had seen the __array_priority__ pro
Timothy Hochberg ieee.org> writes:
> You want __array_priority__; add an attribute __array_priority__ to your
array-like object and set it's value to, say, 10 and ndarrays will defer to your
object.
Thank you very much. I had seen the __array_priority__ property mentioned in
the Numpybook, but i
On Fri, 12 Jan 2007 14:07:23 -0600
"Zhou, Mi" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Python on the same machine was built with MSVS2005. I think it is
> capable of building python modules.
>
> Interestingly, if I replace "floor" with "ceil" in that line of code. It
> will build just fine, and of
On 1/12/07, Torgil Svensson <[EMAIL PROTECTED]> wrote:
On 1/12/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
[CHOP]
> the core. I'm sure it's less efficient, but you shouldn't need to parse
the
> data structure information very often.
I believe that'll be more common than you think; for exam
On 1/12/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
> Things that act like arrays, but have different storage methods. This
> details of this still seem pretty vague, but to the extent that I can figure
> them out, it doesn't seem useful or necessary to tie this into the rest of
> the array in
Hi,
Python on the same machine was built with MSVS2005. I think it is
capable of building python modules.
Interestingly, if I replace "floor" with "ceil" in that line of code. It
will build just fine, and of course, the Numeric.floor() will work just
like Numeric.ceil():
static void * floor_dat
Zhou, Mi wrote:
> Hi,
>
> I am trying to build Numpy-1.01 in windows using "python setup.py
> build". My C compiler is MSVS2005.
Hmm. I was pretty sure that MSVS2005 was not capable of building Python
extension modules that work with the official Python interpreter builds. That
doesn't explain o
On 1/12/07, Neal Becker <[EMAIL PROTECTED]> wrote:
> How about:
>
> 1. A memory concept, of which buffer is an example.
> 2. A view concept.
> 3. A variety of common concrete types composing 1+2.
Is there any difference between a view and an array that shares memory
with another array?
For acces
On 1/12/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> This is true. So at what level do we propose the API. Single-item
> access for sure, but what about
>
> array_interface->get_block_from_slice() ?
>
> Such a thing would be very useful for all kinds of large data-sets, from
> images, and v
On 1/12/07, Adam Jenkins <[EMAIL PROTECTED]> wrote:
I have written my own array class, let's call it "myarray", which behaves
like a numpy.ndarray. I would like to support binary operators with mixed
operand types, i.e.:
lhs + rhs
where one of the operands is a myarray object, and the other i
Hi,
I am trying to build Numpy-1.01 in windows using "python setup.py
build". My C compiler is MSVS2005. The compiler throws an error about
umathmodule.c:
"__umath_generated.c(72): error C2099: initializer is not a constant."
Tried with Numeric-24.2, it gives the same error.
The line of code
I have written my own array class, let's call it "myarray", which behaves
like a numpy.ndarray. I would like to support binary operators with mixed
operand types, i.e.:
lhs + rhs
where one of the operands is a myarray object, and the other is a
numpy.ndarray object.
The problem is that I want
On 1/12/07, Travis Oliphant <[EMAIL PROTECTED] > wrote:
Neal Becker wrote:
> I believe we are converging, and this is pretty much the same design as
I
> advocated. It is similar to boost::ublas.
>
I'm grateful to hear that. It is nice when ideas come from several
different corners.
> Storage
On 1/12/07, Neal Becker <[EMAIL PROTECTED]> wrote:
I believe we are converging, and this is pretty much the same design as I
advocated. It is similar to boost::ublas.
Ah, *that* Neal Becker.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion
Dear all,
I've recently installed the last releases of numpy and scipy (tar
archives from scipy.org).
I encountered two problems:
1) During the configuration it seems the information from my site.cfg
is not read.
2) Installation using atlas optimized lapack/blas libraries didn't work
1) My site
Travis Oliphant wrote:
> Neal Becker wrote:
>> I believe we are converging, and this is pretty much the same design as I
>> advocated. It is similar to boost::ublas.
>>
> I'm grateful to hear that. It is nice when ideas come from several
> different corners.
>> Storage is one concept.
>>
>>
Neal Becker wrote:
> I believe we are converging, and this is pretty much the same design as I
> advocated. It is similar to boost::ublas.
>
I'm grateful to hear that. It is nice when ideas come from several
different corners.
> Storage is one concept.
>
> Interpretation of the storage is an
I believe we are converging, and this is pretty much the same design as I
advocated. It is similar to boost::ublas.
Storage is one concept.
Interpretation of the storage is another concept.
Numpy is a combination of a storage and interpretation.
Storage could be dense or sparse. Allocated in
Charles R Harris wrote:
>
>
> Well, the common machines are 32 bit and 64 bit, so for instance
> extended precision (usually 80 bits) ends up as 96 bits (3*32) on the
> first and 128 (2*64) bits on the second, with the extra bits ignored.
> The items in c structures will often have empty spaces
29 matches
Mail list logo
