This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: zlib monotonic test -- false assumptions or bug in zlib.lib
Type: Stage:
Components: Library (Lib) Versions: Python 2.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: prikryl, rhettinger
Priority: normal Keywords:

Created on 2003-08-08 07:35 by prikryl, last changed 2022-04-10 16:10 by admin. This issue is now closed.

Messages (3)
msg17676 - (view) Author: Petr Prikryl (prikryl) * Date: 2003-08-08 07:35
Hi,

This bug was observed for Python 2.3c1, but probably is 
the same in Python 2.3 final.

I have discovered (by accident) that the assumption in 
test_zlib.py, class CompressTestCase, test_monotonic()
or build on a false assumption ("higher compression 
levels should not expand compressed size"), or the zlib 
version 1.1.4 contains a bug.

The test fails when the hamlet_scene sample is modified. 
Try to remove the empty line from the very beginning of 
the sample. Then the results for level 2 is better that for 
level 3 and the result for the level 4 is better than for 
level 5. The compressed sizes are:

level=0, length=245801
level=1, length=5325
level=2, length=4946
level=3, length=6052
level=4, length=2750
level=5, length=2769
level=6, length=2751
level=7, length=2388
level=8, length=2388
level=9, length=2388

Petr
msg17677 - (view) Author: Petr Prikryl (prikryl) * Date: 2003-08-14 05:39
Logged In: YES 
user_id=771873

I did ask the authors of zlib.  It seems that everything is fine 
except the assumption about "bigger is better" which seems 
natural at first ;-)  The monotonic test should add some 
comment that it may fail. See below:

On Wednesday, August 13, 2003, at 01:45  AM, Petr Prikryl 
wrote:
> My question is: Are the assumptions about the monotonic
> results correct?  In other words, is the Python test correct,
> or is the implementation of the Python wrapper correct
> (i.e. of the enclosed C code), or is there a bug in the
> implementation of deflate()?

[and Mark Adler answered]

It's a feature.  There is no problem with deflate or with the 
Python wrapper.  The compression results, especially on small 
files, are not necessarily monotonic with compression level.  
The compression level determines how hard deflate looks for 
longer matches.  However slightly longer matches do not 
always improve the compression, since it takes more bits to 
encode the longer distances back those matches occur.

mark

msg17678 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-08-31 04:38
Logged In: YES 
user_id=80475

Thanks for the research.
Removed the test.
See:

Lib/test/test_zlib.py 1.24 and 1.23.8.1.
History
Date User Action Args
2022-04-10 16:10:33adminsetgithub: 39034
2003-08-08 07:35:38prikrylcreate