On Wednesday, 27 May 2020 at 16:53:37 UTC, jmh530 wrote:
Not always true...many languages support column-major order
(Fortran, most obviously).
if your column major matrix is implemented as
matrix[row_index][column_index]
then ok no puppies will be hurt. But I dont see much value in
such
On Thursday, 28 May 2020 at 00:51:50 UTC, 9il wrote:
snip
Actually it is a question of notation. For example, mir-lapack
uses ndslice as column-major Fortran arrays. This may cause
some headaches because the data needs to be transposed in mind.
We can think about ndslice as about column-major
On Wednesday, 27 May 2020 at 16:53:37 UTC, jmh530 wrote:
On Wednesday, 27 May 2020 at 16:07:58 UTC, welkam wrote:
On Wednesday, 27 May 2020 at 01:31:23 UTC, data pulverizer
wrote:
column major
Cute puppies die when people access their arrays in column
major.
Not always true...many
On Wednesday, 27 May 2020 at 16:07:58 UTC, welkam wrote:
On Wednesday, 27 May 2020 at 01:31:23 UTC, data pulverizer
wrote:
column major
Cute puppies die when people access their arrays in column
major.
Not always true...many languages support column-major order
(Fortran, most obviously).
On Wednesday, 27 May 2020 at 01:31:23 UTC, data pulverizer wrote:
column major
Cute puppies die when people access their arrays in column major.
On Wednesday, 27 May 2020 at 01:31:23 UTC, data pulverizer wrote:
Hi,
I have started running Kernel benchmarks calculations using Mir
NDSlice, and I'm getting times that are much slower than
expected.
I've swapped the calculation to row major and it's running as
expected.
Hi,
I have started running Kernel benchmarks calculations using Mir
NDSlice, and I'm getting times that are much slower than
expected. To check that I'm not making an obvious mistake, below
are samples of the code I am using. The way the selection happens
is that the `calculateKernelMatrix`
