效率定製的壓縮算法

我有一個壓縮算法想法，我有兩個問題：效率定製的壓縮算法

我應該處理呢？它會有效嗎？
我該如何優化它？

這是我迄今爲止創建的算法。

int i = 0,j, diff, beginIndex = 0; 
while(i < tmp.length){ 
    j = i; 
    byte first = tmp[i]; 
    int total = 0; 
    while(j < tmp.length && first == tmp[j] && total < 127){ j++; total++;} 

    if(total > 3){ 
     if(beginIndex != i){ 
      diff = i - beginIndex; 
      packed.put((byte)diff); 
      packed.put(tmp, beginIndex, diff); 
     } 
     packed.put((byte)(0x80 | total)); 
     packed.put(tmp[i]); 
     beginIndex = j; 
    } 

    i = j; 

    if(i-beginIndex == 127){ 
     packed.put((byte)127); 
     packed.put(tmp, beginIndex, 127); 
     beginIndex = i; 
    } 
} 

if(beginIndex < i){ 
    diff = i - beginIndex; 
    packed.put((byte)diff); 
    packed.put(tmp, beginIndex, diff); 
}

實施例輸入（每個字母描述了字節）

[A, B, C, D, E, E, B, B, A, A, A, A, A, A, A, A, A, A, A, A, A, B, B, B, B, C, C] = 27 bytes

實施例輸出

[0x80, A, B, C, D, E, E, B, B, 0x8D, A, 0x84, B, 0x82, C, C] = 16 bytes

在實施例0x80表示填充位。代表是否重複以下字母。 0xFF - 0x80 = 0x7F是最大重複次數（127）。所以，0x8D代表下面的字節將重複0xD（13）次

任何想法優化該算法？它會有用還是應該擺脫這個想法？

來源

2015-10-17 webdev

通過將結果與現有的衆所周知的gzip算法進行比較，您可以輕鬆檢查其效率。但是由於字母在現實生活中的數據重複出現的情況相對較少（現有算法已經處理了這些數據並且效率更高），所以我認爲這不會產生很好的結果。 – JJJ

這個算法與[run-length enconding algorithm]（https://en.wikipedia.org/wiki/Run-length_encoding）類似，你可以在互聯網上找到關於它的許多信息。 – sergioFC

您可能會使用拼寫檢查器，尤其是標題。壓縮在20世紀80年代很有趣。在投入大量時間之前考慮你的目標（並且記下兩者）。 – greybeard

問題是，算法的目的是什麼？

爲了發明一些真正新的東西，你需要檢查一下，以前發明了什麼。閱讀一些關於數據壓縮的論文和書籍等等.可以成爲開始的好地方。

如果你只是想練習寫算法，那完全沒問題。繼續改進算法，重構，加速，分析等。

如果您希望您的算法實用，請再次檢查之前創建的內容。開源的壓縮算法，如zlib值得研究。

如果您想檢查您的算法如何與其他算法進行比較，請在一些流行的測試（例如Silesia Open Source Compression Benchmark）上運行該算法。這會給你一個直覺，你的立場（這可能有點令人失望，但不要放棄）。

最後，如果你想玩得開心，只要做你想做的事，不要聽任何人。

來源

2015-10-28 03:51:20 EvgeniyZh

你發明了run-length encoding。大多數壓縮算法已經包含了一種運行長度編碼，它將執行您的實現並在更多情況下更好地工作。所以如果我是你，我不會追求它。

如果您對數據壓縮感興趣，我強烈推薦Managing Gigabytes第2章和第6章作爲非常易讀的閱讀。

來源

2015-10-28 04:04:38 gordy

效率定製的壓縮算法

回答

相關問題