Re: question about cdata type identification

[Adam Strzelecki <ono@...>]

Mike Pall wrote:
>> Otherwise we would need to store this number somewhere close the
>> the cdata too. And when talking about matrices we need also
>> store size of all dimensions.
> 
> Use a variable-length struct (VLS), with the array as the last
> element. Store the dimensions in the struct elements.

Great idea. Maybe you know some trick also to copy just a reference to last VLS field into new VLS?

My idea was to make:
struct {
   size_t offset;
   size_t dimx, dimy;
   double data[];
}

And provide method matrix:row(y) so for { 0, {dimx, dimy}, data } it will return { y * dimx, {dimx, 1}, data } with updated offset but same data, instead doing full memory a copying.

My previous idea was to wrap make Matrix object to be a table with { size = { dimx, dimy ... }, data = <cdata>, offset = 0 }, so when I want to return the matrix row y for example I just make a new table { size = { dimx }, data = <same cdata>, offset = y * dimy } so both objects share same cdata.

Of course there's a problem if you want to take out the column, then you need to do copying, but it doesn't matter so much.

Luiz Henrique wrote:
>> Matrix accessor is my big big pain!!! The option M[x][y] is highly
>> inefficient but somewhat convenient. I'm using the direct access
>> M[M.pitch * y + x] for optimized routine but I propose the syntax:
>> 
>> m:get(i, j)
>> 
>> to the user. Quite ugly but I don't have anything better.
> 
> How about using __call and writing m(i,j)?

Good question. Gonna try that too. Wonder it this call will be somehow inlined by LuaJIT or we need a table lookup per each call?

Regards,
-- 
Adam Strzelecki