numerical Lua?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

numerical Lua?

Ben-63
I am learning Lua and find it has no sciLua or numLua projects. (Python has many. And I don't know why python is a good language to do matrix computing.). I am wondering if no array in Lua is a problem to manipulate matrixes and vectors.

Does the following description imply that Lua is a good languge for scietific problems?

====================
Copied from http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/jucs05.pdf
====================
Until Lua 4.0, tables were implemented strictly as hash tables: all pairs were
explicitly stored. Lua 5.0 brought a new algorithm to optimize the use of tables
as arrays: it optimizes pairs with integer keys by not storing the keys and storing
the values in an actual array. More precisely, in Lua 5.0, tables are implemented
as hybrid data structures: they contain a hash part and an array part. Figure 2
shows a possible con guration for a table with the pairs "x" ! 9:3, 1 ! 100,
2 ! 200, 3 ! 300. Note the array part on the right: it does not store the integer
keys. This division is made only at a low implementation level; access to table
elds is transparent, even to the virtual machine. Tables automatically and dynamically
adapt their two parts according to their contents: the array part tries
to store the values corresponding to integer keys from 1 to some limit n. Values
corresponding to non-integer keys or to integer keys outside the array range are
stored in the hash part.

==========================
Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

Luis Carvalho-2
> I am learning Lua and find it has no sciLua or numLua projects. (Python has
> many. And I don't know why python is a good language to do matrix
> computing.). I am wondering if no array in Lua is a problem to manipulate
> matrixes and vectors.

I beg to differ:

http://luaforge.net/projects/numlua

It's not as maintained as I'd wanted it to be, but it's fairly usable.

> Does the following description imply that Lua is a good languge for
> scietific problems?

Definitely.

Cheers,
luis.

--
A mathematician is a device for turning coffee into theorems.
        -- P. Erdos

--
Luis Carvalho
Applied Math PhD Student - Brown University
PGP Key: E820854A <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

Ben-63
Hi,
 
I downloaded the code but don't know how to use it. Sorry. I could not compile the code successfully under Windows.
 
If numlua can deliver matlab or fortran like matrix manipulation syntax, it definitely rules.
 
Ben

 
On 4/22/06, Luis Carvalho <[hidden email]> wrote:
> I am learning Lua and find it has no sciLua or numLua projects. (Python has
> many. And I don't know why python is a good language to do matrix
> computing.). I am wondering if no array in Lua is a problem to manipulate
> matrixes and vectors.

I beg to differ:

http://luaforge.net/projects/numlua

It's not as maintained as I'd wanted it to be, but it's fairly usable.

> Does the following description imply that Lua is a good languge for
> scietific problems?

Definitely.

Cheers,
luis.

--
A mathematician is a device for turning coffee into theorems.
       -- P. Erdos

--
Luis Carvalho
Applied Math PhD Student - Brown University
PGP Key: E820854A <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

Luis Carvalho-2
> I downloaded the code but don't know how to use it. Sorry. I could not
> compile the code successfully under Windows.

Ah, don't worry: it's not your fault. I haven't fixed the win32 settings in
the Makefiles. Anyway, I've just released a win32-binary version of numlua.
Please check http://luaforge.net/projects/numlua again.

> If numlua can deliver matlab or fortran like matrix manipulation syntax, it
> definitely rules.
 
Well, it does. And it is faster than Matlab in many respects -- loops, for
instance -- thanks to Lua. I'll take some time this summer to write some
documentation and fix some bugs. Any comments are welcome!

Cheers,
luis.


--
A mathematician is a device for turning coffee into theorems.
        -- P. Erdos

--
Luis Carvalho
Applied Math PhD Student - Brown University
PGP Key: E820854A <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

SevenThunders
I have a few questions about numerical lua.

1)  I am on a 32 bit x86 windows box and I'd like to link in tuned version of BLAS such as atlas.
It's not clear how to do this with the current source.  What would be nice is to simply have a separate .dll containing the standard BLAS and perhaps LAPACK libraries that could be swapped out.  Is there any chance luamatrix.dll does this?  I notice that you have Fortran source which probably means you are not using the standard cblas wrappers for blas. In fact I did a dumpbin on luamatrix.dll and confirmed this.  Apparently luamatrix.dll includes additional routines other than the standard blas, which means swapping out  different blas libraries is not possible in the current setup.

2)  Is there a convenient C or maybe C++ API for the library?  The thought here is to facilitate the ability to extend the library in a straightforward manner, perhaps with the help of tolua or SWIG.  Normally anything that needs to iterate over individual matrix elements should probably be written in C and then the interface extended to LUA.  The high level logic, gui's etc. could then remain in LUA.

I would dearly like to see a standard numerical library like this for LUA and it looks like you have a pretty good start here just playing around with it.  I actually implemented an interface like this between LUA blas and additional user defined libraries for a client, but alas can not release it since it's proprietary.
Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

SevenThunders
In reply to this post by Luis Carvalho-2
I am pleased at how complete your port is.  You've overloaded arithmetic operators and have even included support for N-d arrays. It is almost as easy to use as Matlab!  However there is still a performance issue which surprised me.  On my windows xp box  (amd x2 3800) I ran a simple benchmark that inverts some matrices and performs some other calculations.  I then ran the equivalent code in Matlab 6.5.

The results are
NumLua 24 sec.s
Matlab. 15.2 sec.s

here's the code for each

LUA

u0 = os.time()
x = matrix(100,100)
I = matrix.eye(100)
for i,j in x:entries() do
                x[i][j] = math.random()
end
for q=1,1000 do
        x = I + matrix.inv(x)
end
u1 = os.time()
print(u1-u0)

Matlab
tic ;
x = rand(100,100) ;
I = eye(100) ;
for q=1:1000
    x = I + inv(x) ;
end
toc


Now since I used your binary distribution I'm not using tuned BLAS libraries, but then again neither is Matlab.  (I think 6.5 uses Atlas but I'm not sure).  Your code does a lot of type checking, but then again so does Matlabs.  I would have expected Matlab to incur more overhead and therefore the LUA code to be more competitive.  

One of the big attractions for using LUA for numerical applications is it's easy interface to C, (with the help of maybe tolua or SWIG).  With C doing the heavy number crunching, one can get a factor of 5 or 6 improvment in speed over Matlab.  (Contrary to the claims of some speed is still of huge importance for numerical applications.  I have Matlab scripts that take 2 days to run, even on my overclocked dual core athlon)

LUA is great for configuration and high level logic.  I have used it this way before with great success.  The problem now with the NumLua approach,  with all the syntactic sugar, is that an overhead penalty is being paid that defeats the purpose of using LUA.  If we want free numerical software,  SciPy is a lot more mature and also has a nice C interface.  

Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

Luis Carvalho-2
In reply to this post by SevenThunders
Sorry about the delay... still in the end-of-semester marathon. :)

> I have a few questions about numerical lua.
>
> 1)  I am on a 32 bit x86 windows box and I'd like to link in tuned version
> of BLAS such as atlas.
> It's not clear how to do this with the current source.  What would be nice
> is to simply have a separate .dll containing the standard BLAS and perhaps
> LAPACK libraries that could be swapped out.  Is there any chance
> luamatrix.dll does this?  I notice that you have Fortran source which
> probably means you are not using the standard cblas wrappers for blas. In
> fact I did a dumpbin on luamatrix.dll and confirmed this.  Apparently
> luamatrix.dll includes additional routines other than the standard blas,
> which means swapping out  different blas libraries is not possible in the
> current setup.

There's actually an error in the Makefiles: only blas and lapack should be
linked to luamatrix.dll, but some other libraries are also being linked. I'll
fix that for the next release. I'm planning to release a quick fix version,
0.2.1, with a revamp of the Makefiles (including something suitable for MinGW)
and a few bug fixes.

You can link luamatrix.dll against dynamic/shared blas and lapack or any other
linear algebra kernel; check the Makefile in src for a few examples. I chose
Fortran sources to ease function calling and to offer more flexible linking
schemes (I guess. :)).


> 2)  Is there a convenient C or maybe C++ API for the library?  The thought
> here is to facilitate the ability to extend the library in a straightforward
> manner, perhaps with the help of tolua or SWIG.  Normally anything that
> needs to iterate over individual matrix elements should probably be written
> in C and then the interface extended to LUA.  The high level logic, gui's
> etc. could then remain in LUA.

Yes, there is. Check the include files (in your case, luamatrix.h
specifically) for the C API.

> I would dearly like to see a standard numerical library like this for LUA
> and it looks like you have a pretty good start here just playing around with
> it.  I actually implemented an interface like this between LUA blas and
> additional user defined libraries for a client, but alas can not release it
> since it's proprietary.

Bummer.

Cheers,
luis.

--
A mathematician is a device for turning coffee into theorems.
        -- P. Erdos

--
Luis Carvalho
Applied Math PhD Student - Brown University
PGP Key: E820854A <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

Luis Carvalho-2
In reply to this post by SevenThunders
> I am pleased at how complete your port is.  You've overloaded arithmetic
> operators and have even included support for N-d arrays. It is almost as
> easy to use as Matlab!  However there is still a performance issue which
> surprised me.  On my windows xp box  (amd x2 3800) I ran a simple benchmark
> that inverts some matrices and performs some other calculations.  I then ran
> the equivalent code in Matlab 6.5.
>
> The results are
> NumLua 24 sec.s
> Matlab. 15.2 sec.s
>
> here's the code for each
>
> LUA
>
> u0 = os.time()
> x = matrix(100,100)
> I = matrix.eye(100)
> for i,j in x:entries() do
> x[i][j] = math.random()
> end
> for q=1,1000 do
> x = I + matrix.inv(x)
> end
> u1 = os.time()
> print(u1-u0)
>
> Matlab
> tic ;
> x = rand(100,100) ;
> I = eye(100) ;
> for q=1:1000
>     x = I + inv(x) ;
> end
> toc

Just a quick comment: you can gain some speed by using locals

local u0 = os.clock()
local x = matrix(100, 100)
local I = matrix.eye(100)
for i=1,matrix.size(x,1) do
        local r = x[i] -- i-th row
        for j=1,matrix.size(r) do
                r[j] = math.random()
        end
end
for q=1,1000 do x=I+matrix.inv(x) end
print(os.clock()-u0)

or even some functional flavor

local u0 = os.clock()
local x = matrix(100, 100):map(function(v) return math.random() end)
local I = matrix.eye(100)
for q=1,1000 do x = I+matrix.inv(x) end
print(os.clock()-u0)

That won't save you much time, of course, since the bulk of the computation is
in the inv loop.

> Now since I used your binary distribution I'm not using tuned BLAS
> libraries, but then again neither is Matlab.  (I think 6.5 uses Atlas but
> I'm not sure).  Your code does a lot of type checking, but then again so
> does Matlabs.  I would have expected Matlab to incur more overhead and
> therefore the LUA code to be more competitive.  

Matlab uses Intel's MKL on Intel chips and ATLAS on AMDs. Moreover, Matlab
uses JIT to accelerate loops. However, I'm very positive that you can still beat
them by simply using optimized BLAS and LAPACK versions. I haven't tried
anything on Windows yet, but I think we can even use Matlab's libs! I made a
few benchmarks on a Xeon a few months ago and the results were encouraging:
around a 7 fold difference (!) for matrix entrywise operations -- that is,
something like x[i][j] = x[i-1][j+1] + 2. Matrix operations (sum, transpose,
multiplication) gave me similar results for both platforms because the
performance here is mainly due to blas/lapack libraries. I'll try to reproduce
the test and post the code later.

> One of the big attractions for using LUA for numerical applications is it's
> easy interface to C, (with the help of maybe tolua or SWIG).  With C doing
> the heavy number crunching, one can get a factor of 5 or 6 improvment in
> speed over Matlab.  (Contrary to the claims of some speed is still of huge
> importance for numerical applications.  I have Matlab scripts that take 2
> days to run, even on my overclocked dual core athlon)

Other attractions for numerics: lexical closures, coroutines, and proper tail
recursions. Not to mention speed and powerful semantics (Matlab cells are a
big "hack" compared to Lua tables).

> LUA is great for configuration and high level logic.  I have used it this
> way before with great success.  The problem now with the NumLua approach,
> with all the syntactic sugar, is that an overhead penalty is being paid that
> defeats the purpose of using LUA.  If we want free numerical software,
> SciPy is a lot more mature and also has a nice C interface.  

Numlua is very, very green. I have a lot plans for it -- sparse matrices,
quadratures, FFTs, plots, more statistics -- but no time for now. OTOH, there
are quite a few features in Numlua already, and I'll definitely dedicate some
love to them this summer and build a more stable and user friendly package.

Cheers,
luis.


--
A mathematician is a device for turning coffee into theorems.
        -- P. Erdos

--
Luis Carvalho
Applied Math PhD Student - Brown University
PGP Key: E820854A <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

Diego Nehab-3
In reply to this post by SevenThunders
Hi,

Two possibilities for the speed difference.  Here are my
guesses.

> for q=1,1000 do
>         x = I + matrix.inv(x)
> end

Is the above code generating a new 100x100 matrix at each
iteration?  I'd be surprized if Matlab didn't optmize this
to operate on the matrix 'x' itself, instead of creating a
new matrix and copying it over 'x'.  This eliminates a lot
of memory allocation, copying, and a lot of garbage
collection.

It woudl be *very* hard to optimize this in Lua. You'd need
at least two changes.

One is on the semantics of something like

     x = matrix(100, 100)
     y = x

I don't know if NumericLua does it, but you'd have to create
a copy of x and place a reference to it on y, instead of
just pointing y to x.  It would be nice if you did this by
copy-on-write.  Matlab does something similar to that with
function arguments.

The problem is that you'd still need a change to Lua
metametods. Perhaps Lua 5.2 could have it. We'd need
access to an optional l-value. In expressions such as

     x = a  +  b + c
     x = (a + b) + c

the first operation would have changed x. The second would
receive x both as a target and a source. This means
you'd have to implement your operations in such a
way that the source and target can be the *same*, which is
not trivial for things like matrix multiplication.

> for i,j in x:entries() do
> x[i][j] = math.random()
> end

I didn't look at the code, but the syntax above suggests you
are creating a temporary object for x[i], which then
receives the [j] indexing. This has got to be slower than
doing something like x(i, j). I know the syntax looks
better, but I x(i, j) is also fine and could be *much*
faster.

Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

SevenThunders
In reply to this post by Luis Carvalho-2
Again I want to emphasize that this is a real nice effort.  I just would like to see some things improved, primarily in the area of performance.  Unfortunately it's not a trivial exercise.  You do a lot of type checking, and I don't think you are, or can do lazy evaluation of vector or matrix expressions.  (Maybe the LUA experts could weigh in here.  Is there any way to do lazy evaluation inside lua?)

My approach to this problem was not nearly as elegant as yours, but it was a heck of a lot faster.
The first thing I did was generate a C include file filled with Macros that handled special case calls to the BLAS and LAPACK libraries, that are commonly used, such as matrix multiplies,  triangular matrix back substitutions etc. etc.  I had a set of wrapper routines that worked directly off of my main matrix structure.

If you use a garbage collector at the C level it makes the C level matrix operations a lot easier to do.  Thus I modified lua and the C code to use the Hans Boehm garbage collector (only two lines of code need to be changed to do this as discussed elsewhere).  Now I don't have to worry about memory leaks and the macros make it fairly straightforward to implement any matrix math in C.  

My philosophy was that anything that had to loop over matrix elements or loop over multiple matrix operations should be in C and should link to BLAS or routines optimized for BLAS (e.g. Lapack) whenever possible.  Thus having a good C api is even more important than the LUA interface.  

On the LUA side I want to be able to do things like view the matrices or submatrices and perhaps graph the results out using gnuplot and control the C code, and insert LUA tables of parameters into the C code.  Thus one wants to automate the interface to the extent possible (tolua and swig are great for this.)

As a final point, on a windows box, there is a library interface issue.  f2c.exe appends an underscore to all fortran routines.  However on windows all the BLAS libraries I've used do not do this.  Atlas leaves the fortran names unchanged and AMDs acml libraries does the same for their C stubs, but capitilizes the names of the Fortran routines so that every routine has two entry points.

I might be able to help, but some more thought would have to go into how to address the performance issues in a reasonable manner.
Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

Alex Queiroz
Hallo,

On 5/7/06, SevenThunders <[hidden email]> wrote:
> expressions.  (Maybe the LUA experts could weigh in here.  Is there any way
> to do lazy evaluation inside lua?)
>

     It's possible attaching to a table a metatable with a __index
metamethod set.

--
-alex
http://www.ventonegro.org/
Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

SevenThunders
In reply to this post by Diego Nehab-3
Yes that's why I was wondering if it is possible at all to do lazy evaluation in LUA.  I know C++ does it using ugly template hacks.   Such things are normally  in the purview of functional languages.  I am not complaining though, I like LUA nice and simple.  I hardly ever use the more advanced features anyway.

No doubt Matlab no longer copies the matrix for sub-expressions that are just thrown away.  It has gotten a bit better.  It is stil very slow when it comes to loops however.  It is encouraging to hear that Louis is seeing some performance gains on his benchmarks.  I should try figuring out how to link it to acml BLAS and see if that improves things.

By the way changing x and I to local in my code had no effect on the overall time (at least within a second).  I wonder if it would be faster if run in luajit?
Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

Luis Carvalho-2
In reply to this post by Diego Nehab-3
Hi Diego,

> Two possibilities for the speed difference.  Here are my
> guesses.
>
> >for q=1,1000 do
> >        x = I + matrix.inv(x)
> >end
>
> Is the above code generating a new 100x100 matrix at each
> iteration?  I'd be surprized if Matlab didn't optmize this
> to operate on the matrix 'x' itself, instead of creating a
> new matrix and copying it over 'x'.  This eliminates a lot
> of memory allocation, copying, and a lot of garbage
> collection.

Yes, a new 100x100 matrix is being generated/collected at each iteration.
I also think that Matlab should be very sensitive to l- and r-values and
should feature a very specialized parser, as you suggested. I have thought
about this memory reallocation issue before, and took the shortest lazy path
of assuming the user would be smart enough to find this bottleneck in his
code and transfer it to C using the API, that is, I didn't want to hack the
parser at that time (and still don't) :).

A not-so-lazy approach would be to provide an "in-place" optional parameter
to most of the functions in the library. I'm postponing this kind of change
until a have a more stable version of NumericLua and more suggestions :). But
you're right: there's a great overhead due to memory allocation, copying, and
collection.

> It woudl be *very* hard to optimize this in Lua. You'd need
> at least two changes.
>
> One is on the semantics of something like
>
>     x = matrix(100, 100)
>     y = x
>
> I don't know if NumericLua does it, but you'd have to create
> a copy of x and place a reference to it on y, instead of
> just pointing y to x.  It would be nice if you did this by
> copy-on-write.  Matlab does something similar to that with
> function arguments.

Matrices are treated as similar to tables as possible, and so y would be a
reference to x in your example. If the user wants a copy, that should be
explicitly stated with y = x:copy() or y = x() (matrix calls are treated as
slicing; more on that below).

What do you mean by copy-on-write? Making a copy of x only when y is written?
Wouldn't it be better to just let the user decide if he wants to copy or just
reference? Isn't worse to copy when not needed?

> The problem is that you'd still need a change to Lua
> metametods. Perhaps Lua 5.2 could have it. We'd need
> access to an optional l-value. In expressions such as
>
>     x = a  +  b + c
>     x = (a + b) + c
>
> the first operation would have changed x. The second would
> receive x both as a target and a source. This means
> you'd have to implement your operations in such a
> way that the source and target can be the *same*, which is
> not trivial for things like matrix multiplication.

That would be great indeed. Let's wait for Lua 5.2 and see what can be done.
I just want NumericLua to be as clean as possible, running on top of vanilla
Lua and harmonically with other libraries, like Mike Pall's LuaJIT. If more of
the parser/lexer is exposed in future versions of Lua, the better (macros?
"native" token filter?).

> >for i,j in x:entries() do
> > x[i][j] = math.random()
> >end
>
> I didn't look at the code, but the syntax above suggests you
> are creating a temporary object for x[i], which then
> receives the [j] indexing. This has got to be slower than
> doing something like x(i, j). I know the syntax looks
> better, but I x(i, j) is also fine and could be *much*
> faster.

Actually there's no temporary object creation. Each row is created along with
the matrix they belong to, and so getting x[i][j] simply involves two __index
lookups. In critical cases -- if we want to beat Matlab :) -- the loop above
can be made faster by, for example, using locals:

for i=1,x:size() do
        local r = x[i]
        for j=1,r:size() do
                r[j] = math.random()
        end
end

I had a previous version where x(i,j) would also index x, but on several
benchmarks this approach came out just a bit faster than x[i][j]. I then decided to
use calls to implement matrix slicing, that is, x(i,j) now returns the submatrix
of x from row i to row j.

Thanks for the food-for-thought,
Luis.


--
A mathematician is a device for turning coffee into theorems.
        -- P. Erdos

--
Luis Carvalho
Applied Math PhD Student - Brown University
PGP Key: E820854A <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

Diego Nehab-3
Hi,

I always wanted to replace Matlab's scripting language with
Lua, but I have to admit it has some strenghts when it comes
to syntax.

Anyways, Matlab appart, it would be great to have some of
that functionality available to Lua scripts and I really
appreciate your effort. I thought about doing it myself, but
I never had the guts/time. :)

> Yes, a new 100x100 matrix is being generated/collected at
> each iteration.  I also think that Matlab should be very
> sensitive to l- and r-values and should feature a very
> specialized parser, as you suggested. I have thought about
> this memory reallocation issue before, and took the
> shortest lazy path of assuming the user would be smart
> enough to find this bottleneck in his code and transfer it
> to C using the API, that is, I didn't want to hack the
> parser at that time (and still don't) :).
>
> A not-so-lazy approach would be to provide an "in-place"
> optional parameter to most of the functions in the
> library. I'm postponing this kind of change until a have a
> more stable version of NumericLua and more suggestions :).
> But you're right: there's a great overhead due to memory
> allocation, copying, and collection.

I didn't mean you should hack the parser. I was just giving
my opinion on why the code is slower than Matlab.

Yes, one approach would be to provide functions such as

     matrix:add(other)
     matrix:mul(other)

and so on, that operated in-place. Although I hate the
syntax, it seems like this could be offered as an
alternative to the "performance critical" applications.

> Matrices are treated as similar to tables as possible, and
> so y would be a reference to x in your example. If the
> user wants a copy, that should be explicitly stated with y
> = x:copy() or y = x() (matrix calls are treated as
> slicing; more on that below).
>
> What do you mean by copy-on-write? Making a copy of x only
> when y is written?  Wouldn't it be better to just let the
> user decide if he wants to copy or just reference? Isn't
> worse to copy when not needed?

I was talking about replicating the semantics of Matlab in
Lua.  I don't know if you care about it or not. But I am sure
users will compare the two things.

This isn't possible with the current Lua API.  Variables can
only hold references to userdata. There is no way to tell
how many references exist to a given matrix.  There is not
even a way for you to always copy on assignments, if you
wanted to be conservative.

On the other hand, take for example code like this

     m = ones(100, 100)
     print(m[1][10])

It doesn't make sense to allocate a 100x100 matrix since you
know all its values are 1s. So you could instead create an
implicit matrix, that always returns 1s.

If the user later does something like

     m[1][100] = 3

you could then explode the matrix. This is one flavour of
lazy evaluation. You could also play tricks with an
associated table that could hold the changes, until there
were so many changes that it was better to create a
full matrix.

Another example is the (in my opinion wonderful) matlab
syntax for "ranges".

    m(1:2, 1:2:10) = m(4:5, 21:2:30)

This is not valid syntax in Lua for several reasons. Not
only because of the ':'. A function call can't be an
l-value, and there is no "assignment" metamethod.

It would be very nice if you could provide a similar
operation in NumericLua. I am not sure what it would look
like, but this is one of the strenghts of Matlab. :/

Regardless of the syntax, all these "ranges" could be
represented implicitly. That would be much more efficient
than allocating memory for all of them.

[]s,
Diego.
Reply | Threaded
Open this post in threaded view
|

Re: numerical Lua?

SevenThunders
In reply to this post by Luis Carvalho-2
I think perhaps another approach is warranted for getting the desired speed up.
What I think should be done is to write, in Lua preferrably, an application specific compiler to
compile a strict subset of LUA containing numLua matrix/complex/floating point expressions into C.

The code would ideally compile some reduced syntax LUA functions into C, compile them,  link against BLAs and/or Netlib math libraries as well as NumLUA internal libraries and generate a dynamic library (.dll or .so) that is then loaded into Lua into a specified table.  Since the current implementation is dynamically typed (at least for it's matrix type), we could require some type specifications within a specially formatted comment field.  

I have used a similar approach to handle certain kinds of Matlab code, and there are automated Matlab interface generators that do some similar work.
(see h2mex
http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=3138&objectType=file )

The beauty of this approach is that rapid prototyping ala Matlab would still be available within the LUA interpreter.  After debugging is finished, one would then launch the NumLua compiler on a file containing LUA routines with the added annotations.  The end result would (hopefully) be a high speed version of the routines that were just debugged.