[Shootout-list] Ray tracer developments

[Sebastien Loisel]

This is an omnibus email, I'm really busy with a bunch of papers right
now and haven't had the time to reply to everything.

 * Raytacer

> Given that the OCaml implementation is much shorter, am I allowed to use =
this
> "room" to implement a slightly more efficient algorithm?

I think your C++ version is longer than it needs to be. There is no
need for virtual functions and derived classes. Keep in mind that
you've done several iterations of the ocaml and just one of the C++.

* On the proportion of floating point code and the 25 test limit

If there's going to be some sort of decision that 5 programs (say) and
only 5 programs are allowed in the FP category then I would like to be
consulted as to what 5 programs these should be. I joined this effort
to try to improve the scientific computing aspect, which is my field.
The numerical codes present in the current shootout look nothing like
traditional or forward-looking scientific computing benchmarks, except
for n-body. If we have such a budget, I would like to know it, and
then I would like to reallocate this tight budget as efficiently as
possible to the highest quality test possible.

* On magic numbers in FP code.

This is good practice in the field of scientific computing. For
instance, the magic numbers in n-body are astronomical measurements.
In other cases, there are large and unwieldy algebraic relations, but
seeing sqrt(pi * ((1 + (pi^2)) / ((pi^3) - (sqrt(2 + exp(-3)) * (pi^(1
/ (2 + exp(-3)))))))) instead of 1.09453934 doesn't give any useful
information. Moreover, much of the time there is no closed-form
algebraic expression for the quantities.

Sebastien Loisel