connect four (game)

[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