On 27/11/2017 13:57, Chris Angelico wrote:
On Mon, Nov 27, 2017 at 10:38 PM, bartc <b...@freeuk.com> wrote:
Your decoder was straight-up buggy, and tests would have proven this.
I created my Python version after the abysmal results from other Python
decoders I tried which didn't work at all, gave the wrong results,
didn't support other subsampling ratios, or hung. Or if they did work,
they took forever.
I suggest you compare my version with some of those.
The first time I looked at a jpeg decoder, it was a massive C library of
about 30 different source files. Sometimes you need to take short-cuts.
My version generates images which are indistinguishable from those
derived via other decoders.
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?
In certain C implementations, rounding the results of integer division
could go up or down. This is a post from comp.lang.c from 2008:
"Nate Eldredge" <n...@vulcan.lan> wrote in message
news:8663mf144q....@vulcan.lan...
> Mr. Burns <burns@snpp.invalid> writes:
>
>> Hi group,
>>
>> suppose I have a grid of cells of size (R,C) and coordinates
>> (0..R-1,0..C-1) and
>> I'm translating pixel coordinates to grid coordinates by dividing by
cell
>> size.
>>
>> Now, all works well for values >= 0, but for values < 0 I'm getting
>> inconsistent results.
>>
>> On one platform, division of negative numbers rounds towards negative
>> infinity, i.e., (-1 / 10) gives -1. (this is what I want)
>>
>> On another platform (solaris), rounding is towards zero, and (-1 /
10) is
>> 0!
>>
>> All numbers are plain ints.
>
> The C99 standard specifies truncation towards zero (like your Solaris
> compiler). However, the previous C90 standard left it up to the
> implementation to decide which way to round when one of the operands is
> negative, as long as it is consistent with the % operator.
Exactly what the problem was with my jpeg program where a number from my
language and compiler ended up as 187, but on C compiled with gcc as
186, I can't remember. I /think/ it was to do with such rounding.
This is not a big deal: one program ends up with a pixel value of 186
(in a range of 0 to 255), and another with 187. The true value in the
original photo may have required a value somewhere between 186 and 187,
so both values could be considered wrong!
Which, if I'm not misunderstanding the specs, is the case for pretty
much every compression scheme in current use - including JPEG.
JPEG uses lossy compression. The resulting recovered data is an
approximation of the original.
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.
I'm fairly certain the OP's program didn't work perfectly first time. So
some procedure had to be followed to try it and decide if it behaved
according to the specification they had in mind.
I believe that process can also be called 'testing'. And in this case,
involving a visual GUI, it really demands tests verified by a human
rather than spending the next six months writing automatic test
procedures that simulate mouse input and examine the pixels on the
screen to see if they correspond to what should happen.
> Your decoder was straight-up buggy, and tests would have proven this.
How did YOU determine it was buggy; unit-tests? And did you just do what
everyone else does?
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
