[Fwd: Re: [Shootout-list] Ray tracer developments]

[Simon Geard]

This is a multi-part message in MIME format.
--------------050908000508040001080703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sent off list by mistake.

Simon

--------------050908000508040001080703
Content-Type: message/rfc822;
 name="Re: [Shootout-list] Ray tracer developments"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: [Shootout-list] Ray tracer developments"

Message-ID: <4274E932.2020805@whiteowl.co.uk>
Date: Sun, 01 May 2005 15:35:30 +0100
From: Simon Geard <simon@whiteowl.co.uk>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Harrop <jon@ffconsultancy.com>
Subject: Re: [Shootout-list] Ray tracer developments
References: <200504291905.30517.jon@ffconsultancy.com> <b7975ab805050105247712510b@mail.gmail.com> <200505011424.33061.jon@ffconsultancy.com>
In-Reply-To: <200505011424.33061.jon@ffconsultancy.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jon Harrop wrote:

>On Sunday 01 May 2005 13:24, Sebastien Loisel wrote:
>  
>
>>I think your C++ version is longer than it needs to be. There is no
>>need for virtual functions and derived classes.
>>    
>>
>
>The inheritance hierarchy is certainly one of the most verbose parts. But what 
>would you use instead? You could use a tagged union, but that is much more 
>common in C than in C++.
>
>  
>
>>Keep in mind that 
>>you've done several iterations of the ocaml and just one of the C++.
>>    
>>
>
>Well, 11 iterations of the OCaml (starting from scratch) and then two 
>iterations of the C++ starting from a working OCaml program.
>
>  
>
>>* 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.
>>    
>>
>
>That was just an idea I proposed. Nobody in authority has agreed to it. I 
>agree that you should be responsible for many of the FP intensive scientific 
>computing benchmarks. As these aren't really relevant to the scientific 
>computing that I do, I'll concentrate on the non-FP ones.
>
>  
>
>>* On magic numbers in FP code.
>>
>>This is good practice in the field of scientific computing.
>>    
>>
>
>No, this is an awful (but all too common) practice in the field of scientific 
>computing and, if you were my student, I would fail you for saying that! :-)
>
>  
>
I'm with Sebastion on this. Properly commented code with e.g. ref to 
page x of Abrimowitz & Stegun is all that is needed.

>>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.
>>    
>>
>
>The algebraic expression tells you the formula from which the digits are 
>derived, which is very relevant information and belongs in the program. You 
>wouldn't determine the memory contents of an initialised struct and then 
>allocate it by bits, would you?
>
>  
>
So when you're doing Gaussian integration you have formulae for the 
weights and zeroes of your chosen polynomial? I don't and I would fail 
any of my students that did.


Simon Geard


--------------050908000508040001080703--