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.

Title: zlib monotonic test -- false assumptions or bug in zlib.lib
Type: Stage:
Components: Library (Lib) Versions: Python 2.3
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

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, 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

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

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 
> 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.


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

Thanks for the research.
Removed the test.

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