[Shootout-list] Stuff

[Sebastien Loisel]

> 1. Get rid of the magic numbers (e.g. 0.8888... / 2.).

You could replace them with formulae for the Chebyshev nodes and weights.

> 3. Don't use macros in C++.

They're part of the language. Get rid of type inference in ocaml.

> 4. If "sin(x ln x)" is not an appropriate function then use an appropriat=
e
> f(x) =3D sin(x ln x) sin(100 ln 100 + (x - 100) (1 + ln 100))

That function's not much better. An "appropriate function" would be
one that requires much finer quadrature over some part of the domain.
Maybe sin x^2. The sin(x ln x) choice is related to question #1 of the
SIAM 100 digit challenge.

> 5. Perhaps it would be better to provide the function externally, so as t=
o

Using templates, you kind of expect it to get inlined.

> 6. What about integrating an interpolated function from a given data set?

I don't mind but there's a sort of conundrum. I'd expect to get one or
more intbits per piece of spline. However, unless the spline is degree
6 or higher, a single intbit will integrate it with 0 error. So
basically to be honest you'd have one intbit per spline piece. On the
other hand, it is not safe to rely on the error estimation to detect
discontinuities in the derivatives of order less than 6 (it can do
that, but only for impractically tiny values of eps.) See ode
integrators and events (for instance, in the book by Hairer et al.)

> 7. Should "eps" be related to the machine precision?

As long as eps>>machine epsilon, no. It's related to how much work you
want to do.

> Both programs and Mathematica, I get "8.787608...". The C++ took 4.366s a=
nd
> the OCaml took 5.942s.

According to Xavier Leroy, he thinks the ocaml in the original spends
most of its time in the heap code. I think what you've done is reduced
that penalty by increasing the amount of floating point calculations
that need to be done, and ocaml is smart enough to unbox the floating
point calculations because they're all in a single function. Is that
right?

> The FFTW-based MEM program from my book is of practical interest and, I
> believe, is representative of many other tasks performed by scientists.

I'd have to see the code.

> > > 1. Sphere: Recursively subdivide an icosahedron to produce an arbitra=
rily
>=20
> I think you're thinking of uniform subdivision. I'm thinking of adaptive

I was thinking of both. For adaptive subdivision I use map<> data
structures, which will make Fortran, C etc... a pain. My Ph.D. is
about PDEs on the sphere, so I use this too.

> Some languages may be able to represent the lists (and their tails) as ar=
rays

Which languages?

> I'm not sure what you mean by "building the multiresolution thing".

http://www.eso.org/projects/esomidas/doc/user/98NOV/volb/node316.html

> Yes. What about raytracing the old sphere-flake? Something like this:

Do you build a special sphere-flake-ray test that's efficient, or do
you stick one million spheres in a general purpose hierarchical
bounding volume? The latter seems more interesting for the benchmark,
but I suspect it'll be large loc.

> > > 7. Symbolic manipulation: write a program which can symbolically
> Yes, C++ won't be very good at this problem either. Efficient pattern mat=
ching

I'm not convinced that C++ will be less efficient. It will be more
tedious to write though.

Sebastien Loisel