Repository navigation
Discussion for creating ArrayFire lua API #1
Description
Activity
Yes indeed, but I think it would be nice to have a general purpose library in LUA first and then integrate with Torch.
Sure, just need your input on how to get started. Once the rest of the team implements the base API you can look into integrating with Torch.
Hi.
The v3.1 announcements of a few days ago came just as I've been wanting a more powerful linear algebra solution, so I'd actually be willing to have a go at this in a couple weeks or so.
I guess I'd just grind my way through this list, plus any classes that show up in their signatures? Apart from a few operators (operator= and the mutate ones) it looks straightforward enough...
Was there already more discussion on this elsewhere? Are there any conventions that have arisen in the other language bindings that should be followed?
(This would be stock Lua, since that's what I need at the moment. Though indeed, as @gpryor says, LuaJIT bindings shouldn't present much trouble at all.)
@ggcrunchy The ideal way is to wrap the C API functions rather than C++. I was thinking of beginning work on this at some point soon as well. Perhaps I can create the skeleton and we can split up the work between us ?
Sounds great.
For context, my plan is to piggyback on this effort to make a plugin (Windows initially, more as time goes on) for the Corona SDK, where the primary language is Lua.
I've taken cursory looks in the past at both toolkits. I'm not sure whether "such a project" referred to my plugin or this binding, but I'll keep Luapower's packaging / bundling in mind.
As far as "problems... to which arrayfire is geared", my foremost use case will be 2D graphcut textures, following Kwatra et al.. I've got the bare minimum done, but the various refinements, at least per the authors' recommendations, call for FFTs / convolution, summed area tables, and multiresolution splines. SATs in stock Lua worked well, I found, but suffice it to say any but the most tiny of 2D FFTs did NOT. 😃 I have a second application involving thin-plate splines that uses QR decomposition as a first step. (LU ought to work too.) Up to around 40 x 40 a pure Lua implementation has been fine, then the cost ramps up rather quickly.
I also regularly see questions for CV- and audio analysis-related problems, so this being available could finally change some of the answers from "somebody has to provide the mechanisms" to "somebody has to sit down and implement it".
It's completely untested at this point and lacking a few details still (locations of non-Windows binaries, CUDA- and OpenCL-specific stuff, etc.), but I went ahead and made a cdef, since in putting the stock Lua binding together I was basically iterating the whole ArrayFire function list anyhow: ArrayFire FFI
It's not 100% ready, but getting there.
