Submission declined on 4 December 2025 by Fermiboson (talk). This draft's references do not show that the subject meets Wikipedia's criteria for inclusion. The draft requires multiple published secondary sources that: provide significant coverage: discuss the subject in detail, not just brief mentions or routine announcements; are reliable: from reputable outlets with editorial oversight; are independent: not connected to the subject, such as interviews, press releases, the subject's own website, or sponsored content. Please add references that meet all three of these criteria. If none exist, the subject is not yet suitable for Wikipedia. If you would like to continue working on the submission, click on the "Edit" tab at the top of the window. If you have not resolved the issues listed above, your draft will be declined again and potentially deleted. If you need extra help, please ask us a question at the AfC Help Desk or get live help from experienced editors. Please do not remove reviewer comments or this notice until the submission is accepted. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs Declined by Fermiboson 6 months ago. Last edited by RetroRetry 27 days ago. Reviewer: Inform author. Resubmit Please note that if the issues are not fixed, the draft will be declined again.

• Comment: Ok, so I kind of understand why the reviewers haven't got to this yet. But having some level of quantitative knowledge, I'm perplexed.
  1. The article is not comprehensible for anyone who doesn't know information theory. It is not possible, for example, to tell what the differences are between the different variants, without knowing about them beforehand.
  2. The article is also not comprehensible for anyone who does know information theory. All lossless data compression algorithms, to my knowledge, make use of the fact that character chains have a nontrivial kernel; it is in fact mathematically necessary for a compression algorithm to exist. What is different for this algorithm?
  3. Most importantly for Wikipedia - I'm nearly 100% certain that the article subject is notable. The current references, however, are basically entirely primary, which means that the sources as they stand don't meet GNG. There is a massive academic corpus on compression algorithms, review of compression theory and its implementation, etc. Use it. Fermiboson (talk) 21:46, 4 December 2025 (UTC)

LZP (short for Lempel-Ziv-Prediction) is a lossless data compression algorithm that primarily leverages the insight that the characters immediately prior a given position tend to be strong predictors for the immediately following characters^[1][2]. It's closely related to PPM context modeling and Markov chains^[3].

For every input byte within the input stream, the previous N bytes are gathered to create a finite context of size (or order) N. This context is hashed by a hash function and used to retrieve the corresponding entry in a hashtable, which returns a reference to an earlier position in the already‑processed data. The upcoming sequence of bytes is then compared with the data at that reference point, and the length of the matching segment is determined.

The result of this comparison is written in the output stream using an encoding scheme such as:

• If the matching length is zero, a flag indicating a negative match is recorded followed by the literal byte itself.
• If the matching length is one or greater, a flag indicating a positive match is recorded and then the length of the match is written.^[2][4][5][6]

The technique was first described by Charles Bloom in 1996.^[1][2] and later popularised in hobbyist publications related to the demoscene due to its low implementation footprint^[7]. It is often used as a pre-processor for stronger LZ-type or entropy compressors to improve their compression ratio without a noticeable speed penalty^[8]

In the same year of the publication of LZP, another similar algorithm was indipendently published as part of the PPP protocol called Predictor^[9]. Multiple online sources have used their name interchangeably even thought the two algorithms are distinct^[10][11]. To be specific, Predictor is different to LZP in that it stores literals instead of pointers in the hashtable, doesn't require jumping to previous locations in the stream and matches single bytes only without attempting to find multi-byte matches.

• Hashtable size: A value of 2¹⁶ bytes or greater is typical on modern implementations^[11]. Early implementations on memory-constrained hardware would choose a lower amount such as 2^{12 [1][2]} or 2⁸ at the cost of a worse compression ratio.
• Context size: How many input bytes should be taken into account when creating the hash. This choice affects the compression ratio of the algorithm and its effect varies with the nature of the input data. In the case of LZP, those are the N most-recent bytes in the stream. The size of the context is also often referred to as the order of the algorithm (eg. an order-3 algorithm has a context size of N=3 bytes).
• Hash function: The hash function's purpose is to minimize collisions and should be constructed to yield a hash with representable size equivalent to the hashtable size, which allows the direct output of the hash function to be used as the index to the hashtable without additional mapping steps. The hash function takes as input the context string C, usually internally reinterpreted as an integer for more efficient computation.

Documented variants of LZP involve different choices of parameters, further processing with entropy coders or different hashtable matching systems:

• LZP1: A fixed order-3 hashed context model was used, with a hashtable of size 2¹² and match lengths were written using variable-length integers. The hash function H = ((C >> 11) ^ C) & 0xFFF was chosen, which yields a 12-bit hash that can be immediately used in a hashtable of size 2¹².
• LZP2: Same as LZP1, but literals and match lengths were written with a Huffman coder.
• LZP3: A order-4 context model was used with a 2¹⁶ table size. Literals and match lengths were written with a order-I Huffman coder. Notably, the table also contains the contexts, together with a mechanism that finds the highest-order context that does have a match in the table. The hash function H = ((C >> 15) ^ C) & 0xFFFF was chosen.
• LZP4: A order-5 context model was used and a table with 2¹⁶ entries, with order-1 arithmetic coding of match lengths and order-4 PPM encoding of literals. In this version, table entries aren't a single pointer, but contain instead a substantially more complex 2-dimensional linked list of pointers.^[2][4]

• Compression ratio: In the worst case, LZP's output can be at most 12.5% larger than the input, as an all-miss string yields 9 bits per 8 input bits. The best case ratio is dependent on the maximum value representable by the chosen encoding of the match length. On real-world data, LZP alone provides modest compression, around 50% or worse for written text or worse for more general-purpose textual data with markup^[2][11][12], but pairing it with an entropy coder has the potential to cut in half again the ratio.^[13]
• Speed: due to the lack of tree structures, search buffers or the need for dynamic allocations, LZP is always relatively faster than any algorithm that would employ these techniques such as entropy coders and most LZ variants.^[12]
• Memory usage: The predictor table is fixed, no dynamic allocation is required during processing except for LZP4. It is recommended to choose a table size that would fit in the CPU cache^[13] to avoid the table overflowing into RAM, which would cause substantial performance degradation.

• Lempel–Ziv
• Reduced Offset Lempel-Ziv
• Markov chain
• Prediction by partial matching
• Lossless compression