[Shootout-list] Re: sumcol - when the correct answer is wrong :-)

[Brent Fulgham]

On 2004-09-21 14:13:41 -0700 Brian Hurt <bhurt@spnz.org> wrote:
> On Tue, 21 Sep 2004, Brent Fulgham wrote:
> 
>> I disagree.  I don't think it is reasonable behavior
>> to allow integer overlow, unless the developer
>> explicitely codes to allow this behavior.  Silently
>> handling a catastrophic condition like this is why
>> cancer patients receive overdoses of radiation,
>> satellites crash into planets, and corporate loan
>> balances turn into "credit" values.
> 
> This is a statement of opinion about what a language should do.  
> Wether it's 
> "correct" or not, several languages *BY DESIGN* do not do this.  
> Including C 
> and C++.
> 
> If it's a test to see how the language handles big integers, that's 
> one 
> thing.  But I comment that the "correctness" attributes of the 
> languages are 
> beyond the scope of the project as I understand it.  If we're going 
> to get 
> into correctness arguments, let's bring up static vr.s dynamic typing.

The test is to sum a column of integers from a text file.  The file is 
quite large
in some cases, resulting in a large result.

I fail to see how it can be termed "correct" behavior for an entry to 
sum the
numbers and arrive at an overflow.  That is not the sum of the 
integers from
the file.

I agree that we can postulate cases where overflow would happen to give
a useful result -- but that would only apply to particular classes of 
problems.
If we wish to implement a test that takes advantage of that feature, 
we can
certainly do so.  But I will not agree that 'sumcol' can treat 
overflow as a
successful result.

> As for the timing constraints, there are two solutions.  One is to do 
> more 
> work per iteration.  2^30 clock cycles is the better part of a second 
> even on 
> the fastest CPUs these days.  Or, two, run the test multiple times.

This would be reasonable as well.  We could perhaps add some kind of 
busy work
in the program to help eat up the time.  But that's no longer 
measuring the speed
of line-oriented I/O that the test was originally designed to measure.

-Brent