[Numpy-discussion] design issues - octave 'incompatibilities'
python-ml at nn7.de
Sun Jul 24 11:42:30 CDT 2005
On Sat, 2005-07-23 at 12:06 -0700, Robert Kern wrote:
> Soeren Sonnenburg wrote:
> > Dear all,
> > 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 ?
> Not everyone is interfacing with optimized FORTRAN code. Those who are
> are usually using ATLAS as their BLAS, and ATLAS has row-major versions
> of the BLAS subroutines. Row-major is C's convention and
> numarray/Numeric largely follow that. There are of course some
> performance issues when interfacing with FORTRAN code that expects
> column-major, but there would be other performance problems if
> numarray/Numeric were column-major and interfacing with row-major code.
Well but why did you change to the C version then ? Well maybe if it is
about optimizing stuff seriously one could work with the transpose
> Often, though, a "row" vector can also be used in place of a "column"
> vector. Although sometimes not:
You are right, thanks!
> > Are there more elegant ways to do this ? Which issues are likely to be
> > fixed in the future ?
> None. They're not broken, just different from what you are used to.
Thanks a lot for your very helpful mail!
Do you know whether mixing slices and arrays will be supported at some
point a[:,[0,1]] ?
More information about the Numpy-discussion