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