[Numpy-discussion] design issues - octave 'incompatibilities'
oliphant at ee.byu.edu
Mon Jul 25 14:11:08 EDT 2005
Soeren Sonnenburg wrote:
>I am new to numarray and as I am trying to use it day-by-day
>I am now wondering about certain numeric/numarray design issues. Please
>forgive me / correct me as I probably misunderstood certain issues.
>-- Why did you choose row-major instead of column major format as
>practiced by R/octave/matlab... Doesn't that mean performance problems
>as fortran/blas is optimized if you work with the transposed version ?
>-- why do vectors have no 'orientation', i.e. there are only row but no
>column vectors (or why do you treat matrices/vectors differently, i.e.
>have vectors at all as a separate type)
I think others have responded to these questions well.
>-- How can one obtain submatrices from full matrices:
>numarray gives only elements (which is very, very rarely needed and
>should IMHO rather be some extra function):
I thought about this quite a bit because I initially felt as you did
before beginning work on scipy.base (Numeric3). I wondered if the
right choice had been made. After some thought and discussion, I
decided this approach was more general and flexible, and agreed with the
numarray design. Therefore, this works in scipy.base the same.
Also, scipy.base does allow mixing slices and lists like you want:
a = scipy.base.array([[1,2,3],[4,5,6],[7,8,9]])
array([[1, 2], [4, 5], [7, 8]], 'l')
>-- why don't you allow iterating over the whole matrix via a single
You can with scipy.base with a.flat[index] but ravel(a)[index] always
The reason is that Numeric uses the concept of reduced-dimensionality
arrays so that
a[index] for a 2-d array returns a 1-d array not an element of the 2-d
It may be different then you are used to but I think it is a better choice.
More information about the NumPy-Discussion