connect four (game)

[nospam.Chris Angelico]

On Mon, Nov 27, 2017 at 10:38 PM, bartc <bc at freeuk.com> wrote:
> On 27/11/2017 03:04, Michael Torrie wrote:
>>
>> On 11/26/2017 08:39 AM, bartc wrote:
>>>
>>> The problem was traced to two lines that were in the wrong order (in the
>>> original program). I can't see how unit tests can have helped in any way
>>> at all, and it would probably have taken much longer.
>>
>>
>> What makes you think that?  Surely other decoders were doing the right
>> thing and you could compare your output against theirs?  JPEGs may be
>> lossy but the path through the decoder should be deterministic.
>>
>> Or even if every decoder is slightly unique, at least yours should
>> output self-consistent data.
>
>
> The original used some floating point code, I changed that to use integer
> code (eg a combination of multiplying and shifting; it make a difference on
> compiled version, perhaps not so much in .py).

The JPEG spec says what a given file should decode to. So you can use a
reference implementation to confirm that your code is correctly decoding. Even
if you might legitimately encode the same image in different ways, each of
those encoded files should decode to one exact image, regardless of which
decoder is used.

Your decoder was straight-up buggy, and tests would have proven this.

> But also (IIRC) there was a difference in taking the remainder of negative
> integer division, where different compilers may round up or down.

In every compiler, interpreter, and CPU that I've ever used, the remainder has
been well-defined. In what situation was it ill-defined, such that different
compilers could do different things?

> Some people are obsessed with having unit tests. Others are the same about
> using debuggers, especially in compiled code.
>
> I've never used either, but I do alright. Some of the stuff I do is
> unsuitable for those for technical reasons, but also some of the problems
> I've come across just don't fit into such patterns.
>
> People should use what works best for them, unless they're in a team where
> the have to use certain tools and working methods.

Yep, and if "producing buggy code that fails to comply with the spec" is what
works best for you, then please don't tell us that we're advocating the wrong
thing. Testing might not fix everything, but it does help, especially in those
easy cases where you're working with a pure function that has a single correct
output for a given input. Which, if I'm not misunderstanding the specs, is the
case for pretty much every compression scheme in current use - including JPEG.

For myself, I don't write as many tests as I should. But I'm not going to go
around telling people that tests are a waste of time.

ChrisA