Re: [ANN] GSL Shell 2.2.0 beta1 release
- From: Coda Highland <chighland@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Mon, 17 Sep 2012 13:59:49 -0700
If I might comment on the matter, there's a lot you can do to address
these issues. Having not used GSL Shell myself I only know what I can
see from the source code in your git repo, but your concerns aren't
unaddressable.
> For example in LuaJIT you cannot refer to an element of a matrix like
> m[i, j] as it would be natural for matrices.
You can define the __call metamethod to allow m(i,j) to work. This is
probably more efficient than the two-level approach you're currently
using, although of course it may not necessarily be source-compatible.
(Though you could probably keep the current implementation you have to
avoid breakage.)
> You don't have a specific
> syntax for matrix literals and, more important matrix operations are
> inherently inefficient because evaluation is not delayed. So if you
> write:
>
> a + 2*b + 2*c
>
> where a, b and c are matrices Lua will:
> - create a new matrix equal to 2*b
> - create a new matrix equal to 2*c
> - create a new matrix to sum a + 2*b
> - create a new matrix to sum (a + 2*b) with 2*c
>
> Of course this is a disaster in term of efficiency. The evaluation
> should be delayed to use BLAS operations to evaluate efficiently the
> expression.
>
> This problem exist also for the multiplication by a transpose. The
> BLAS function allows to evaluate it without the need of actually
> creating the transpose matrix but with Lua you cannot.
Is it particularly problematic to introduce proxy objects that expose
the matrix API but are in fact composition operators that don't get
evaluated until it's actually needed? (e.g. when accessing a matrix
element or calculating the inverse) This would be essentially
equivalent to building a string by assembling a table and then calling
table.concat() in order to avoid the intermediate products.
/s/ Adam
Other related posts:
