On Sun, Mar 1, 2009 at 23:56, Andreas Klöckner <[email protected]>wrote:

> On Sonntag 01 März 2009, you wrote:
> > > 1) Careful, terminology trap. F-contiguous != contiguous (what you call
> > > nonlinear) != C-contiguous.
> >
> > cuda is C, no? is "F" something other than fortran?
>
> Nicely set up. :) True, "F" is Fortran. But that's just a convenient name.
> Call them column- and row-major if you wish. There's good reason for both,
> even in a pure C program.
>
> > I think there should be some sort of check.
>
> I already knew *your* opinion. :)


:) I don't know how appropriate it would be, but perhaps you could post the
question on the nvidia cuda forums?


>  > But maybe all of this can wait
> > for your codepy python-aware C structures? I'd like to see some tutorial
> > examples on that when you have time.
>
> Not sure how codepy would help here. I'll try to find time to write a
> tutorial.


I guess I didn't see the row-major and column-major argument above -- I did
notice that the "erroneous" arrays before ndarray.copy() were transposed. On
further thought, if one had Python representations of C data structures,
arrays could be annotated as row-major or column-major (with C indexing --
last index most contiguous -- by default). Then, instead of doing memcpy,
perhaps a programmer could name a struct field (which would be an array in
this case) and copy to that, or (as I am now) copy to an array of fixed-size
structs.

regards,
Nicholas
_______________________________________________
PyCuda mailing list
[email protected]
http://tiker.net/mailman/listinfo/pycuda_tiker.net

Reply via email to