[Shootout-list] Stuff

[Sebastien Loisel]

Welcome Jon,

On 4/22/05, Jon Harrop <jon@ffconsultancy.com> wrote:
> as well as floats. These kinds of things are so difficult to implement in
> most other languages that programs are either at worst intractable (Fortr=
an)
> or at best error-prone (C++).

I have begun working on such problems, attempting to stay within the
limits of the shootout. Look at implicitode and
http://www.math.mcgill.ca/loisel/numerical-integration.html.

To borrow a word from a famous man, I think you misunderestimate C++.

> Regarding some other discussions I've read about in the archives. I think=
 it
> is vitally important to allow people to use common libraries (and to not

I'm specifically designing numerical code that prevents people from
taking advantage of libraries like FFTW and LAPACK. I don't think they
make for insteresting benchmarks.

> 1. Sphere: Recursively subdivide an icosahedron to produce an arbitrarily
> accurate approximation to a sphere (described in the OpenGL Red Book).

I've implemented this many times and it's array+floats, and not even
complicated float calculations, so I don't see why one would want to
do this.

> 3. Discrete wavelet transform: This can be implemented really elegantly u=
sing
> lists, or much more efficiently but less clearly using arrays (at least i=
n
> OCaml).

You will certainly lose if you try lists against arrays. It might be
an interesting test to have, but the main difficulties are the
semi-random memory accesses when building the multiresolution thing,
because the base calculations aren't hard at all, so the test would
have to show some interesting patterns in the languages because I
can't see what's special about it.

> 5. Graphics algorithms: I like the idea of a ray tracer someone suggested=
. How
> about some more algorithms from graphics?

You'd have to be more specific. Raytracing is interesting if you have
some hierarchical data structure to speed up the ray checks, because
it gives an interesting algorithm, but many of the other graphics
algorithms I know either take a fair bit of code to write or depend on
some numerical algorithm which might as well be implemented on its
own.

> 6. Calculator or BASIC: a simple lexer, parser and interpreter.

Yes, writing toy parsers, the great success of all functional
languages. I'm not that keen on writing a yacc benchmark, but that's
just me.

> 7. Symbolic manipulation: write a program which can symbolically differen=
tiate
> x^x or multiply out polynomials with arbitrary-precision integer coeffici=
ents
> or something.

The arbitrary precision bit makes it difficult. I was going to use it
in my implicitode test but it pushes everything off into large loc
counts in several languages. I also know why you like this test, and
it's true that it'll increase the loc count of C++ whether you do it
with virtual functions or templates.

Sebastien Loisel