[ANN] Sci-1.0-beta1

  • From: Stefano <phd.st.p@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Tue, 18 Sep 2012 22:51:44 +0100

This is a MIT licensed library for general purpose numerical computing
written entirely in Lua(JIT).

The Sci library is composed of a number of modules:

* alg: vector and matrix algebra operations;
* math: special mathematical functions;
* quad: quadrature (integration) algorithms for real-valued functions;
* fmin,fmax: function minimization and maximization via local and
global algorithms;
* prng: pseudo random number generators;
* qrng: quasi random number generators, also known as low discrepancy
sequence generators;
* dist: statistical distributions.

We refer to the website www.scilua.org for more documentation and for
the download.

Please notice that compared to my other two released libraries (Time
and LJSqlite3), the Sci library is at a less developed stage both from
the code and from the documentation point of view. I am aiming to have
the documentation completeness in line with that of the other two
libraries (examples, ecc ecc).
It's an initial release that I am distributing to gather feedback and
adjust my future developments.
I have done testing on all the modules but I have not used the library
extensively so bugs may be present.
Despite the large list of modules the number of algorithms implemented
is currently limited.

I would really appreciate your feedback regarding this work. Please
report bugs as well if you find them.

Some notes/limitations/todos about the sci.alg library:

* 1-based indexing (a note, not a limitation :P): my experience is
that it's better for my target audience (scientists / engineers /
statisticians who deals with computational problems).
* No support for matrix operators (todo).
* Don't use A[i] to get a row of a matrix, use A:row(i).
* Scalars only on right hand side of binary operators (left hand side
is todo, I decided to forbid it but I have now changed my mind):
y:set(x + 3) -- Ok.
y:set(3 + x) -- Not ok.
* I have considered many different alternatives for the implementation
of expressions and ended up with the one you can see in the code.
Maybe instead of the dispatch table a dynamically generated function
with multiple if conditions could be used but I am not sure if this
would be more efficient. Feel free to propose alternatives, even a
completely different approach. In any case the expressions are
dynamically generated to allow for (up to my knowledge) efficient
indexing and the expression-building functions are cached using as
keys the "types" entering the expression.
* Ignore the undocumented apply functionality, I am now thinking of
something in line with the following to allow multiple arguments:
local abor = alg.toapply(bit.bor)
y:set(abor(y, x)) -- y and x are vectors.
The way expressions containing functions are built should remain close
to the current implementation. The unary minus will have its own
dedicated function.
* Range checks can be disabled by editing sci/alg/config/init.lua.
* No check for aliasing, which is a possibility with sub() (todo as
configuration).
* No check for reading/writing on dead objects (todo as
configuration). This requires __gc on the expressions (not necessarily
with if conditions). It could be that performance is affected with
this check turned on if temporary expressions are used (see next
point) and __gc conflicts with allocation sinking.
* Expressions in tight loops:
-- Outside expression:
local expr = x + y
for i=1,n do y:set(expr) end
-- Versus temporary expression:
for i=1,n do y:set(y + x) end
I have done some benchmarking and which solution is better depends on
the dimensionality: short loops are manually unrolled in set() and in
that case the second choice is usually faster.
If long expressions are build (say more than 6 operators) the compiler
may give up on compiling the temporary expressions. The problem is
solved (for reasonable expression length) by passing -Oloopunroll=30
to LuaJIT, by constructing the expression outside the loop, or by
dividing the expression in multiple independently evaluated parts.
* I have done preliminary benchmarking of a previous version of
sci.alg versus hand-written Lua code (with a nested for loop over the
vector dimension) and versus a C++ library (Eigen) and the results
seemed good. You are encouraged to do some benchmarking and report
back if you have time. Aside from synthetic benchmarks, numbers based
on some real algorithm using sci.alg would be helpful.
* It actually takes a bit more time than I expected to load the
sci.alg module (1/10 of a second :P). If anyone sees something
incredibly inefficient please let me know, I did not spend too much
effort on optimizing this (the time required to do the actual
computations is way larger than 1/10 of a second in the problems I am
dealing with).

Known issues:

* In the differential evolution algorithm if the population is passed
it is modified in-place. This should not be the case (even if the
documentation is not clear on this point).


Stefano

Other related posts:

  • » [ANN] Sci-1.0-beta1 - Stefano