[Shootout-list] Science-related benchmarks

[Sebastien Loisel]

> > > The FFTW-based MEM program from my book is of practical interest and,=
 I
> > > believe, is representative of many other tasks performed by scientist=
s.
> >
> > I'd have to see the code.
>=20
> It's freely available:

Looks good to me. Why didn't you use the conjugate gradient method though?

> > > Some languages may be able to represent the lists (and their tails) a=
s
> > > arrays
> >
> > Which languages?
>=20
> In the shootout? No idea.

Any language anywhere?

> > > I'm not sure what you mean by "building the multiresolution thing".
> >
> > http://www.eso.org/projects/esomidas/doc/user/98NOV/volb/node316.html
>=20
> I'd rather see a really simple function that people can work through to
> You could regard this as a floating-point intensive benchmark.

There isn't that much difference between Haar and the next thing up,
but that's not important. More to the point, I'm not sure the Haar
transform is that interesting. In fortran I'd do it as arrays+floats,
and the computations risk taking a back-seat to the memory accesses.

> > > 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
> Instead of using hierarchical bounding volumes, you could compute the set=
s of
> spheres which intersect horizontal and vertical planes. Then you can rest=
rict

Something like

let rec split x =3D match x with
| [] -> []
| (a,b) :: xs -> (a,(2.0*.a+.b)/.3.0) :: ( (a+.2.0*.b)/.3.0,b) :: (split xs=
)

let rec cantor n =3D
  if n =3D 0
  then [ (0.,1.) ]
  else split (cantor (n-1))

let rec is_in_cantor x n =3D
  if n =3D 0=20
  then true
  else
    let x3 =3D x *. 3 in
    let a =3D floor x3 in
    let b =3D x3 - a in
    ((a < 1) or (a >=3D 2)) & (is_in_cantor b (n-1))

let raytrace x n =3D
  if is_in_cantor x n
  then cantor n
  else []

and then the rest of the benchmark is a bunch of set intersections?
That's not a lot of floating point work if you ask me, but ok.

> Here's my improved C++ version of your integrate benchmark:

Thanks for the code, I will look at it. With sin(x ln x) did you
notice a speed change at all between your versions and my versions?

Sebastien Loisel