On 22/02/2008, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> Is there a ticket on the NumPy trac for this? We won't see it if there
> isn't. Thanks for pointing us to the bug.
It appears to be fixed in SVN (that was quick!). But the Debian bug
report also points out a peculiar unnecessary us
Alan G Isaac wrote:
> On Fri, 22 Feb 2008, Christopher Barker apparently wrote:
>> because that's the whole point of a Matrix object in the
>> first place.
>
> Do you really believe that? As phrased??
yes -- the matrix object is about style, not functionality -- not that
style isn't important
Alex Donaldson wrote:
> compile options:
> '-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
> -Inumpy/core/src -Inumpy/core/include
> -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c'
> gcc: _configtest.c
> sh: line 1: gcc: command not found
This is y
Running from numpy source directory.
non-existing path in 'numpy/distutils': 'site.cfg'
F2PY Version 2_4422
blas_opt_info:
FOUND:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
define_macros = [('NO_ATLAS_INFO', 3)]
extra_compile_args = ['-faltivec',
'-I/System/Library/Framewo
Ondrej Certik wrote:
> On Sat, Feb 23, 2008 at 2:10 AM, Travis E. Oliphant
> <[EMAIL PROTECTED]> wrote:
>> Ondrej Certik wrote:
>> > Hi,
>> >
>> > more details in this bug report.
>> >
>> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467095
>> >
>> > The bug report offers a fix for this
On Sat, Feb 23, 2008 at 2:10 AM, Travis E. Oliphant
<[EMAIL PROTECTED]> wrote:
>
> Ondrej Certik wrote:
> > Hi,
> >
> > more details in this bug report.
> >
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467095
> >
> > The bug report offers a fix for this problem. It seems to me this i
Ondrej Certik wrote:
> Hi,
>
> more details in this bug report.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467095
>
> The bug report offers a fix for this problem. It seems to me this is
> not fixed even in the latest svn.
>
>
Is there a ticket on the NumPy trac for this? We won't see
On Fri, Feb 22, 2008 at 6:57 PM, Alex Donaldson <[EMAIL PROTECTED]> wrote:
> I'm trying to install numpy 1.0.4 on my Intel MacBook Pro with Mac OS 10.4
> and running Python 2.5. When I run python setup.py build I get the
> errors below. Is this a compatibility issue?:
I don't know. Please prov
I'm trying to install numpy 1.0.4 on my Intel MacBook Pro with Mac OS 10.4
and running Python 2.5. When I run python setup.py build I get the
errors below. Is this a compatibility issue?:
Running from numpy source directory.
non-existing path in 'numpy/distutils': 'site.cfg'
F2PY Version 2_4422
Hi,
more details in this bug report.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467095
The bug report offers a fix for this problem. It seems to me this is
not fixed even in the latest svn.
Thanks,
Ondrej
___
Numpy-discussion mailing list
Numpy-
Could you provide more details about this to the ticket I created
based on your email:
http://projects.scipy.org/scipy/numpy/ticket/636
Thanks,
On Thu, Dec 13, 2007 at 3:33 PM, Jonathan Taylor
<[EMAIL PROTECTED]> wrote:
> I was needing an array representation of ndindex since ndindex only
> give
Travis, after reading all the post on this thread, my comments
Fist of all, I'm definitelly +1 on your suggestion. Below my rationale.
* I believe numpy scalars should provide all possible features needed
to smooth the difference between mutable, indexable 0-d arrays and
inmutable, non-indexable
I have 2 user-defined types, and simple arithmetic working for the cases I
registered with PyUFunc_RegisterLoopForType.
I'd like to use automatic conversion to do mixed arithmetic between these 2
types. I did PyArray_RegisterCastFunc, and it seems this allows explicit
conversion:
>>> a
array([(
> Alan G Isaac wrote:
>> I propose that the user-friendly question is:
>> why deviate needlessly from array behavior?
>> (Needlessly means: no increase in functionality.)
On Fri, 22 Feb 2008, Christopher Barker apparently wrote:
> because that's the whole point of a Matrix object in the
> first
Alan G Isaac wrote:
> I propose that the user-friendly question is:
> why deviate needlessly from array behavior?
because that's the whole point of a Matrix object in the first place.
> (Needlessly means: no increase in functionality.)
Functionally, you can do everything you need to do with nump
Neal Becker wrote:
> cmp_arg_types(int *arg1, int *arg2, int n)
> {
> while (n--) {
> if (PyArray_EquivTypenums(*arg1, *arg2)) continue;
> if (PyArray_CanCastSafely(*arg1, *arg2))
> return -1;
> return 1;
> }
> return 0;
> }
>
> IIUC, if can cast (a
cmp_arg_types(int *arg1, int *arg2, int n)
{
while (n--) {
if (PyArray_EquivTypenums(*arg1, *arg2)) continue;
if (PyArray_CanCastSafely(*arg1, *arg2))
return -1;
return 1;
}
return 0;
}
IIUC, if can cast (arg1, arg2), we never compare other args, jus
On Fri, 22 Feb 2008, Christopher Barker apparently wrote:
> It makes me think that M[i] should not even be possible,
> as you would always want one of:
> row vector: M[i,:]
> column vector: M[:,i]
> element: M[i,j]
I propose that the user-friendly question is:
why deviate needlessly from a
Travis E. Oliphant wrote:
> Neal Becker wrote:
>> Now that I have my user-defined type, I want to add some funcs.
>> According to the numpy book, I need to use:
>>
>> PyUFunc_RegisterLoopForType
>>
>> The book says I first need a ufunc. The only way I see to create one is
>>
>> PyUFunc_FromFuncAn
Travis E. Oliphant wrote:
> to behave as you described in your previous post: where M[i] returned a
> 1-d array
My thoughts on this:
As Konrad suggested, row vectors and column vectors are different beasts
,and both need to be easily and intuitively available.
M[i] returning a 1-d array break
A Thursday 21 February 2008, Konrad Hinsen escrigué:
> I agree. In fact, I'd rather see NumPy scalars move towards Python
> scalars rather than towards NumPy arrays in behaviour. In particular,
> their nasty habit of coercing everything they are combined with into
> arrays is still my #1 source of
On Fri, 22 Feb 2008, "Travis E. Oliphant" apparently wrote:
> Do I understand correctly, that by intuitive you mean
> based on experience with lists, and NumPy arrays?
Yes.
In particular, array behavior is quite lovely
and almost never surprising, so matrices should
deviate from it only when th
Neal Becker wrote:
> Now that I have my user-defined type, I want to add some funcs.
> According to the numpy book, I need to use:
>
> PyUFunc_RegisterLoopForType
>
> The book says I first need a ufunc. The only way I see to create one is
>
> PyUFunc_FromFuncAndData.
>
> Is the the correct procedu
Alan G Isaac wrote:
>
>> stop believing that M[0][0] and M[0,0] should return the
>> same thing. There is nothing in Python that requires
>> this.
>>
>
> I never suggested there is.
> My question "how to guess?" does not imply that.
>
> My point is: the matrix object could have more intui
On Fri, 22 Feb 2008, "Travis E. Oliphant" apparently wrote:
> The point is that a matrix object is a
> matrix object and not a generic container.
I see the point a bit differently:
there are costs and benefits to the abandonment
of a specific and natural behavior of containers.
(The kind of beha
>
>> Could you explain to me how you'd like this to be fixed? If the
>> matrix becomes a container of 1-d arrays, then you can no longer
>> expect x[:,0] to return a column vector -- which was one
>> of the reasons the matrix class was created. While not
>> entirely consistent, one workaround
> On Fri, 22 Feb 2008, Stefan van der Walt apparently wrote:
>
>> This is exactly what I would expect for matrices: M[0] is
>> the first row of the matrix.
>>
>
> Define what "first row" means!
>
Konrad has shown that do "get it right" you really have to introduce
three separate thing
On Feb 22, 2008, at 15:55, Travis E. Oliphant wrote:
>> ColumnVector, and RowVector. It would work like this:
>>
>> m = Matrix([[1, 2], [3, 4]])
>>
>> m[0, :] --> ColumnVector([1, 3])
>> m[:, 0] --> RowVector([1, 2])
>>
> These seem backward to me.I would think that m[0,:] would be the
> RowV
Konrad Hinsen wrote:
> On 22.02.2008, at 01:10, Alan G Isaac wrote:
>
>
>> Someone once pointed out on this list that one might
>> consider a matrix to be a container of 1d vectors. For NumPy,
>> however, it is natural that it be a container of 1d arrays.
>> (See the discussion for the distinct
>>> On Thu, Feb 21, 2008 at 12:08:32PM -0500, Alan G Isaac
>>> wrote:
a matrix behavior that I find bothersome and unnatural::
>>> M = N.mat('1 2;3 4')
>>> M[0]
matrix([[1, 2]])
>>> M[0][0]
matrix([[1, 2]])
On Fri, 22 Feb 2008, Stefan van der Walt apparently wrote:
Now that I have my user-defined type, I want to add some funcs.
According to the numpy book, I need to use:
PyUFunc_RegisterLoopForType
The book says I first need a ufunc. The only way I see to create one is
PyUFunc_FromFuncAndData.
Is the the correct procedure?
I wonder, because PyUFunc_From
A Friday 22 February 2008, Stefan van der Walt escrigué:
> Hi Travis,
>
> On Wed, Feb 20, 2008 at 10:14:07PM -0600, Travis E. Oliphant wrote:
> > In writing some generic code, I've encountered situations where it
> > would reduce code complexity to allow NumPy scalars to be "indexed"
> > in the sam
On Thu, Feb 21, 2008 at 04:17:26PM -0800, Christopher Burns wrote:
> Would anyone oppose deprecating the memmap.sync function and replacing
> it with memmap.flush? This would match python's mmap module, and I
> think be more intuitive.
I made the change in
http://projects.scipy.org/scipy/numpy/c
On Thu, Feb 21, 2008 at 07:10:24PM -0500, Alan G Isaac wrote:
> > On Thu, Feb 21, 2008 at 12:08:32PM -0500, Alan G Isaac wrote:
> >> a matrix behavior that I find bothersome and unnatural::
>
> >> >>> M = N.mat('1 2;3 4')
> >> >>> M[0]
> >> matrix([[1, 2]])
> >> >>> M[0][0]
> >>
34 matches
Mail list logo
