octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible (summer of code) projects for Octave


From: Jaroslav Hajek
Subject: Re: Possible (summer of code) projects for Octave
Date: Tue, 4 Jan 2011 14:18:16 +0100

On Mon, Jan 3, 2011 at 8:10 PM, Daniel Kraft <address@hidden> wrote:
> Hi all,
>
> I'm interested to apply for Google Summer of Code with Octave next year
> (provided there will be another GSoC and GNU is again accepted as mentoring
> organization, but I guess both will be true) and in general to look into
> contributing to Octave (although I don't know how much spare time I can
> spend on it outside of something like GSoC at the moment).
>

IIRC, mentors from Google itself are also acceptable under some
conditions. If that's still true, I could volunteer as a mentor. I
used to be a very active Octave developer not so long ago :)

> Octave seems interesting to me in particular since I both use it frequently
> (I've just finished Bachelor's courses in maths and physics and am now doing
> the respective graduate courses where I do a lot of the numerical /
> simulation programs in Octave since it is quite well suited for what I need
> to do there) and am also especially interested both in numerics aspects as
> well as computer language interpreter / compiler implementation.  So far I
> did not dive into the Octave code (besides compiling it from source and
> using the C++ interface),

If you compiled with (almost) all dependencies, that's already a minor
achivement :)

> but have already some experience with language
> implementation in general -- I did implement emacs lisp support partially in
> GNU Guile as another GSoC project two years ago (partially = core language
> except emacs/text editor specific stuff like buffer-local bindings) and am
> working on the gfortran front-end to GCC for three years now.
>
> Ok, sorry so far for the off-topic description of myself.  What I wanted to
> ask is whether there are some ideas for projects to work on that could fit
> for GSoC or in general something which is possibly not "fixing bugs" or
> doing a lot of "minor" improvements but seperate "new" things to work on and
> getting started.

My favorite is implementing the OOP versions of delaunay triangulation
and interpolation functions. See
http://www.mathworks.ch/help/techdoc/ref/delaunaytriclass.html
http://www.mathworks.ch/help/techdoc/ref/trirepclass.html
http://www.mathworks.ch/help/techdoc/ref/triscatteredinterpclass.html

in contrast to the existing delaunay et al. functions, the OOP
approach is not only fancy, it allows you encapsulate & reuse more
important topological data to make things like lookup & interpolation
way faster.
For instance, if you want to triangulate an area nad then lookup
enclosing triangles for a set of points, you'd use delaunay & tsearch
in Octave; the problem is that the latter is sadly inefficient because
it's not able to accept any more information than a plain list of
triangles from the delaunay triangulation (it can't even assume the
triangulation is delaunay).


> Of course, what came first to my mind when thinking about
> this, was JIT or a byte-code VM approach to speed up interpretation of loops
> and other stuff -- but from what I read on the mailing list archives, this
> is already a somewhat "well known" project and I understand that there are a
> lot of difficulties in particular because of the dynamic typing.

And not my favorite one, I must add :)

> Still,
> maybe there are currently some ideas or motivation to try something into
> that direction?  Otherwise, I also read something about attempts to make use
> of multiple cores -- this sounds interesting, too, are the ongoing projects
> towards (or interest in) that?  Some other things that would be useful for
> Octave and the user community?
>

I think what Octave needs to be considered seriously in the future is
better support for high-level parallelism. Low-level cheap stuff like
parallelizing sum() is laughable, IMHO - might be good for MW to boost
their PR image, but in real life that will win you almost nothing. I
and D. Bateman actually experimented with code to parallelize some
element-wise matrix operations, and the results were, IMHO, poor.
Parallelizing costly built-ins like pinv() or fft() is a good idea,
but that's usually best handled by libs that implement them (BLAS,
FFTW). Some mappers (e.g. erfinv) may also fall into this area, and
that should not be hard to do.

The main problem with this is that the interpreter is not remotely
thread-safe, which makes high-level multithreading impossible. One
option is to use multiprocessing instead - look at general/parcellfun
or openmpi on OctaveForge. The other option, of course, is to make
Octave thread-safe. That would be a big enough project without any
doubt, I'm just not sure it's academic enough.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]