Re: [ANN] Sci-1.0-beta1
- From: "M. Edward (Ed) Borasky" <znmeb@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 19 Sep 2012 11:57:30 -0700
Have you looked into combining this with GSL Shell?
On Tue, Sep 18, 2012 at 2:51 PM, Stefano <phd.st.p@xxxxxxxxx> wrote:
> 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
>
--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://j.mp/QCsXOr
How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
Other related posts:
