Şimdi Ara

Histogram Based, Real Time Lossless Data Compression Algorithm λ∈[(ArgMax⇔>∀xω1) (2. sayfa)

Daha Fazla
Bu Konudaki Kullanıcılar: Daha Az
3 Misafir - 3 Masaüstü
5 sn
150
Cevap
11
Favori
13.106
Tıklama
Daha Fazla
İstatistik
  • Konu İstatistikleri Yükleniyor
0 oy
Öne Çıkar
Sayfa: önceki 12345
Sayfaya Git
Git
sonraki
Giriş
Mesaj
  • O nasıl oluyor? Yaz bakalım hemen onuda çürüteyim
  • quote:

    Orijinalden alıntı: Communist

    yapmak istediğin şey hem kayıpsız sıkıştırma hemde aynı işlemi defalarca aynı veriye uygulama eğer doğru anlamışsam (eskiden bende aynı şeyin olabileceğini düşünüyordum cahillik diyorum şimdi ) bunu yapmanın mümkünü yok. önceki mesajımda çok basit bir şekilde açıkladım toplamda 16 kombinasyon alabilen veriyi 8 kombinasyona düşürmenin mümkünü yok geriye kalan 8 kombinasyonu ne ile temsil edeceksin?

    yapabileceğin şey veriyi analiz ettikden sonra yoğun bölgeye göre işlem yapmak aynı veriye 2. sefer işlem yaparsan işe yaramayacak çünkü 1. işlem yoğun bölgeyi zayıflatacak.

    1mb lık dosyayı 10kb ye düşürdün diyelim 1mb de kaç kombinasyon var 10kb de kaç? yalnızca o dosyaya özel bir işlem olur 1mb lik dosyadaki kombinasyon değiştikçe çıktı boyutu büyür bir yerden sonra çıktı boyutu orijinal boyutu aşar.
    "Kayıplı veya kayıpsız olarak sıkıştırılmış veriler normal şartlarda daha fazla sıkıştırılamazlar. Ancak istisna olarak PAQ serisi algoritmalarında bu durum biraz istisna oluşturmaktadır. Bu serideki algoritmaların çalışma performansları anormal yavaştır. Sıralı şekilde bit değeri tahminine dayalı olarak çalışırlar. Ancak onlarda da bir limit var tabi ki."

    Yukarıdaki şekilde bilgi verdiğim halde ilginç cevaplar yazılıyor. Lütfen "PAQ 8" nedir inceleyelim!
    https://www.wikizeroo.org/index.php?q=aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUEFR




  • quote:

    Orijinalden alıntı: Communist

    video ses gibi özel veri tipleri için bu formatlar hakkında bilgi edinmek lazım ama veri tipi özel değilse bunun çözümü malesef yok.

    örnek olması için ufak bir kod yazdım bu kodu çalıştırın 1mb lik bir dosya oluşturacak sonra winrar ile sıkıştırmayı deneyin her seferinde farklı değerlere sahip dosya oluşacak ben birkaç sefer denedim çoğu zaman 1 bayt bile sıkıştırmadı.


    int main(int argc, char *argv[])
    {
    FILE *fp = fopen("dosya.tmp", "wb");
    if(!fp) return 0;
    char *buf = (char*)malloc(65536);
    for(int i=0;i<16;++i)
    {
    unsigned r = rand() * time(0);
    srand(r);
    Sleep((rand() * r) % 100);
    for(int k=0;k<65536;++k)
    {
    buf[k] = rand() % 256;
    }
    fwrite(buf,1,65536,fp);
    }
    free(buf);
    fclose(fp);
    }
    Hangi algoritma olursa olsun yukarıdaki kodu çalıştırıp oluşan 1mb lık dosyayı üst üste beş kere sıkıştırın her seferinde dosya boyutu küçülüyormu büyüyormu.

    Paq8 ile denedim ilk sefer 100kb küçüldü sıkıştırdığım dosyayı tekrar denedim bu sefer 1kb büyüdü.



    < Bu mesaj bu kişi tarafından değiştirildi Communist -- 3 Eylül 2019; 22:23:30 >




  • Communist kullanıcısına yanıt
    Burada sonsuz sıkıştırmadan bahsetmiyoruz. Zaten öyle bir şey söz konusu değil, anlatmıştık. Ancak bahsi geçen algoritma kümesi çok yavaş çalışarak sıkışmış veriler üzerinde de etki gösterir diyoruz. Zaten öyle olduğunu da biliyoruz. Ancak PAQ8 en az 32 gb RAM li bir makinede bir kaç günlük çalışma sonunda tam olarak etkin kullanılabiliyor. O da her seferinde byte lar düzeyinde sıkıştırma yapabilmekte. Senin kullandığın şey muhtemelen çok daha standart parametrelerle elde edildi.

    PAQ8 ile kullandığın parametreleri, işlem süresini ve RAM kullanımını gösteren bir görsel paylaşırsan sevinirim. Benim yaptığım denemelerde büyüme söz konusu olmamıştı.
  • Geçmişin başarısızlığı mı ? Bunu diyen kim ? Hangi vasıfla veya bilimsel yaklaşımla ?

    Eğer değerlerimiz çoğunlukla mükemmel karelerden oluşuyorsa, genel olarak sıkıştırılmış değerlerimiz orijinalden daha kısa olacaktır. Ancak böyle çok özel durumlar gerçek hayatta pek olası değildir. Aksi takdirde uzama söz konusudur. Karekök işlemi yüksek dereceli bitlerin ilk yarısını tutmak ve ikinci yarısını da kaldırmak anlamına gelir. Bu yüzden kayıplar oluşmaktadır. Literatürde de böyle geçmektedir. Yani kayıpsız şekli pratik kullanımda hiç uygun değil! Kayıplı sıkıştırma işlemleri için ise diğer bilinen yöntemlere nazaran daha az verimli.

    https://www.quora.com/Could-square-roots-be-used-to-compress-data-and-treated-as-a-large-number

    http://www.astro.lu.se/~lennart/Astrometry/TN/Gaia-LL-028-19990817-Lossy-compression-using-square=root-coding.pdf

    https://authors.library.caltech.edu/17825/1/Bernstein2010p7278Publ_Astron_Soc_Pac.pdf



    < Bu mesaj bu kişi tarafından değiştirildi Stack -- 4 Eylül 2019; 15:9:0 >




  • Stack S kullanıcısına yanıt
    İndirdiğim yer -https://moisescardona.me/paqcompress-v0-1-released/

    İşlem süresi bir buçuk dk gibi.
    Sonsuz sıkıştırma zaten mümkün değil. Sıkıştırılmış dosya 2. sefer yine sıkışıyorsa algoritma problemlidir.



    < Bu mesaj bu kişi tarafından değiştirildi Communist -- 5 Eylül 2019; 22:45:5 >
  • Communist kullanıcısına yanıt
    Gerçek geliştiricileri tarafından derlenen en son PAQ8 Console sürümü:
    https://encode.su/attachment.php?attachmentid=6715&d=1562845252

    1 mb lik rastgele bir dosya bende ortalama masaüstü i7 bir işlemci ile yaklaşık 5 dk sürüyor. Ancak bu normal mod. Daha yüksek modlarda süre saatlere çıkıyor ve RAM kullanımı da 16 gb nin üstüne çıkıyor. Dediğim gibi bir kaç byte bile olsa azaltıyor ama arttırması mümkün değil. Yani sıkıştıramadığı durumlarda dosyaya yazmıyor ve orijinal dosyayı veriyor.

    Neyse konu sahibi bu tür paylaşımlar yapmamıza kızıyor. Boş ver




  • Stack S kullanıcısına yanıt
    Her şartta işlem yaparsa boyut büyür demek istedim. Çıktı boyutunu kontrol edip orijinal boyuttan büyük çıktığında yazmaması ayrı tabiki.
  • Günde 1-2 saatini verip kısa sürede düşük seviyeli bir dil öğrenebilirsin. Özellikle bitler (ikilik sayı sistemi) hakkında bilgi edinirsen yapmak istediğin şeyin imkansız olduğunu görürsün. Hiç bir algoritma her türlü veri tipinde işe yaramaz. Öyle olsaydı gb larca veri 1 bite kadar düşerdi
    Var olan tüm veri tiplerinin ortak özelliklerini nekadar bilirsen okadar kullanışlı bir algoritma yazabilirsin.
  • @Communist süresiz uzaklaştırılmış. yeni bir sıkıştırma algoritması gibi birşey geliştireceğinize yeni bir iletişim platformu düşünmelisiniz. Önem sırası denen birşey var.

    SEO19: Signed integers, rational numbers, floating point numbers olayı GNU Multiple Precision Arithmetic Library / GMP ile 28 yıl önce çözüldü. GMP ile bir tek "Hello Big Number" uygulaması yaptın mı? Bu işler düşünerek olmaz, tatbik ederek olur. Bir de Steel Bank Common Lisp / SBCL denen bir compiler var, onda hiçbir kütüphane eklemeden 10.000'in faktöryelini bile alabiliyorsun, yani cok büyük degerlerde dahi tam sayı değeri verebiliyor. Denedim.

    Neyse konuyu ziyaret amacım o değil, alternatif iletişim platformlarından bahsetmek ki bunu da forumda hiç göremiyoruz. @Communist akternatif forum için şu adrese gelebilirsin:
    https : // riot . im/app/#/room/#ulke-ve-dunya-gundemi:matrix . org (boşlukları kapatarak) link tıkla. Linklere forum ?campaign linki ekliyor, o linkle açmayabilir. Adres cubugunda aşağıdaki gibi görünmeli:

    Histogram Based, Real Time Lossless Data Compression Algorithm λ∈[(ArgMax⇔>∀xω1)




  • Bunun için biraz kafa yoracağım fakat üstteki programcı arkadaşlarında haksız olduğunu düşünmüyorum ama denemeye değer bir proje.
  • konu başlığını karekök olarak değerlendirip sayının uzunluğunu da veri boyutu kabul edip aşağıdakini yazdım ancak bir tasarruf olmadı
    https://dotnetfiddle.net/Widget/Preview?url=/Widget/ooJRz1
  • C# 'taki BigInt ≠ GMP'deki BigInt. GMP'deki BigInt örneğin 50000! dahi hesaplayabiliyor. C#'ta 50000! hesaplamayı dene.

    Sıkıştırma algoritması konusunda ise ilk mesajım geçerli. O alanda keşfedilecek herşey keşfedildi ve hepsinin implementasyonu da yapıldı. Örneğin lzma, xz, rar 6 bunlar (tar.gz, tar.bz2'ye ek olarak) oldukça yeterli. Senin tasarım diyelim ki onlardan en verimlisi üstüne 10% daha sıkıştırıyor; atcağın taş ürkütceğin kurbağaya değecek mi? Soru budur. Diyelim ki değecek o durumda o tasarımın implementasyonunu yapacak programcı ve onu finanse edecek sermaye bulmalısın. O ayarda bir programcı en az 20binTL aylık alır. Programcılık işi tahminen 3 ay sürse, kenarda 60.000TL'n hazır olmalı. Bunlar yok ise boşuna birşey yazmaya gerek yok.
  • Keşfedilme ve yeni yaklaşımlar mevzusu için hemen canlı örnekler vereyim:

    25 yaşındaki JPEG için kayıplı ve kayıpsız bir çok alternatif geliştiriliyor. Yani JPEG in yerine geçmesi planlanan daha verimli ve gelişmiş bir format lazım. Bu alanda başı yine Google çekiyor. WebP, JPEG XL gibi formatları çok güçlü ekiplerle geliştiriyorlar. Diğer yandan BPG gibi bir alternatif mevcut. (http://xooyoozoo.github.io/yolo-octo-bugfixes/#swallowtail&jpg=s&bpg=s) Elbette daha birçoğu var. Bizlerin bu taraklarda herhangi bir bezi olmadığı için sadece aşağıdaki bahsi geçen teknolojilerin lisans ücretlerini ödeyip kullanıyoruz ve bununla da yeri geldiğinde gurur bile duyuyoruz

    Ses için de MP3 e çeşitli alternatifler geliştirilmekte. Video için de aynısı geçerli. MP4 yerine MP5 mi yoksa AV1 mi geçecek ortalık fena halde karışık. MP4 ve MP5 için muazzam (!) lisans ücretleri bulunmakta ve bunu ödememek için büyük bir topluluk tarafından(IBM, Microsoft, Google, Amazon, Cisco, AMD, Intel, Samsung...) AV1 geliştiriliyor. Ancak sonuç pek iç açıcı değil maalesef. (https://aomedia.org)

    Yani mevzu basit olsa bunca adamın burada işi ne ki? Özetle bu iş bitmedi ve biteceğe de benzemiyor (patent, patent, patent). Aslında konu sahibi SEO19 bu konuda çok haklı.

    İyi bir sıkıştırma alternatifi bulunsa bile vonderplanitz in de dediği gibi bunu adam gibi performanslı şekilde koda döküp ürün haline getirebilecek birileri gerekli olacak. Ve bu gerçekten uzun soluklu bir süreç olacak. Ancak bizim memlekette çok yüksek meblağlar bile ödense o türden kişileri bulmak imkansıza yakındır.

    https://www.mpegla.com/programs/avc-h-264/licensees/
    https://www.cnx-software.com/wp-content/uploads/2017/10/HEVC-License-Price-List.png



    < Bu mesaj bu kişi tarafından değiştirildi Stack -- 8 Eylül 2019; 23:5:48 >




  • Stack S kullanıcısına yanıt
    Azizim, ben daha iyi sıkıştırma algoritması bulunamaz keşfedilemez demiyorum, sadece yeteri kadar bulundu diyorum. mp3 'ten daha kaliteli sıkıştırma formatı yok mu , var. İyi de mp3 atı alıp üsküdar'ı geçti bile. Aktif torrent indiricisiyim, mp3 arşivimde onbinlerce mp3 var kimisi sıkıştırılmamış ses formatı FLAC APE gibi geliyor, direkt 256kpbs veya duruma göre 192 veya 320kbps mp3 yapıyorum. Videodaki VHS Betamax olayı gibi mp3 cok iyi olmasa da bu işi götürdü. Jpeg bırakın iyi olmayı berbat olsa da olayı götürdü.

    Biraz da bu sıkıştırma algoritmasına karşı olma sebebim, daha cok ses getirecek ve daha önemli başka konuların olması. Örneğin FSF 100% gerçek özgür ve gerçek açık kaynaklı mobil işletim sistemi projesini öncelikli listesine aldı, neden? Cunku Android, iOS Google ve Apple'ın kullanıcılara kanalizasyon artığı gibi gördüğü sistemler. Gerçek özgür gerçek açık kaynaklı bir mobil sistem ihtiyacı var. O konuda birşeyler olsa herkesten cok desteklerim.




  • 24 Ağustos 2019 16:10:10
    Windows 10 bu yaz dâhili Linux kerneline sahip olacak


    "Piyasada şu an aktif olarak gelişimine devam eden 287 tane Linux Distro var. Ömrünü tamamlayıp gelişimine devam etmeyenleri sayamayız zaten. Bunca dağınık Distro olana kadar bir araya gelinip daha güçlü birkaç Distro geliştirilse ve yazılım çeşitliliği/desteği vs. açısından ciddi bir ekosistem kurulsa (Android gibi) MS falan kalmayacak. Ancak olmuyor ve yeni bir bilgisayar alırken 600 küsür TL Windows için para veriyoruz. Ofis yazılımlarını söylemiyorum zaten. Yazık demiyorum haktır diyorum bu duruma " demişim.

    Yani BSD gibi başarılı bir işletim sistemi dışında yüzlerce özgür Linux distrosu olduğunu belirtmiştim. Bahsettiğin şey zaten var yani. İsteyen istediği şekilde kendince özelleştirip yeni Distrolar türetebiliyor. Basit bir süreç olduğu Linux dağıtımı sayısından belli. Android ve IOS da zaten Linux temelli. Özetle bir Linux dağıtımı yada varolan bir tanesinin yaygınlaşıp tekeli yıkması için gerekli kullanıcı desteği olmadan olmaz. Samsun bile zamanında kendi mobil işletim sistemini geliştirdi ancak gerekli kullanıcıya ulaşamadığı veya ilgi görmediği veya başka nedenlerle devam ettirmedi. Huawei gibi bir şirket anında Amerika ya diklenip yeni bir mobil işletim sistemi geliştirebiliyor. Kullanılır veya kullanılmaz ama bunlar var ve isteyenler tarafından yapılabiliyor.

    En basitinden MS Office alternatifleri ücretsiz "Libre Office", "Open Office", "Free Office" gibi başarılı yazılımlar var. Kim kullanıyor peki? Kaç kişi? Çok az. Tamamen alışkanlıklardan ileri gelen bir durum. Yani bana bu iş hiç çekici gelmiyor.

    Diğer yandan milyarlarca dolarlık bir sektör var codec'lerde. Ve her önüne gelen bu işi yapamıyor ve milyon dolarlık lisans ücretlerini güzel güzel ödüyorlar. Yeni bir codec için onlarca firma ancak bir araya gelip bir şeyler yapabilir ama yerine göre yine beceremiyorlar. Fark bu yani.

    Neyse konuyu daha dağıtmayayım yoksa konu sahibi yine kızabilir bize




  • Joel Spolsky, 21.Mart.2000https://www.joelonsoftware.com/2000/03/21/converting-capital-into-software-that-works/ makalesinin giriş paragrafıdır:

    The common belief is that when you’re building a software company, the goal is to find a neat idea that solves some problem which hasn’t been solved before, implement it, and make a fortune. We’ll call this the build-a-better-mousetrap belief. But the real goal for software companies should be converting capital into software that works.


    Türkçesi (birebir değil, düzeltmeli ve hafif yorumlu şekilde)

    Yazılım deyince herkes bir problemi çözen güzel bir fikir bulup onu uygulayıp küçük bir servet yapmayı anlıyor. Bu yaklaşıma biz 'daha iyi bir fare kapanı yapmak' diyoruz. Fakat yazılımdaki asıl amaç, daha iyi fare kapanı yapmak değil, parayı etkili bir yazılıma dönüştürmek olmalıdır.

    Spolsky'nin açısından bakınca, bu konu külliyen gereksiz.

    Alttaki yorumlar bu konu ile ilgili değil, geneldir:

    Bir yazılım işinden bahsetmeden önce ortada para olacak, bütçe olacak.
    Amerika ve Avrupa'da yazılımla ilgili iş ilanlarının coğunda para ve bütçe önceden belirtilir. Programcı paraya ve yapılacak işe bakar ve bu parayı ne kadar etkili şekilde yazılıma dönüştürebileceğini düşünür. ABD ve AB'de ayrıca devlet desteğiyle başlanan yazılım projeleri hedefi 12'den vuran işler çıkarmıştır. 1980'lerde Unix kernel yeni donanımlar, artan RAM kapasiteleri karşısında problem yaşıyordu. DARPA (Defense Advanced Research Projects Agency) CMU universitesinde 7 kişilik bir ekibi finanse ederek Mach kernel'i destekledi. Mach kernelden alıntı yaparak macOS başta olmak üzere birçok Unix sistemi çekirdeğini güncelledi, bugünkü OS'lerin bu kadar sorunsuz olmasına katkıda bulundu.

    İlla ki para olmak zorunda da değil. Tox projesi örneğin hiç kimsenin metelik atmamasına rağmen popülerlik kazandı, ve 2019 da başarıyla geliştiriliyor, neden? Cunku insanların Internette güvenli, mahremi ve güvenilir iletişim yapmasını sağlayarak gerçek bir eksiği kapatıyor. Zcash projesini bilir misiniz? O da güvenli ve mahremi iletişimin finansal tarafta da uygulanmasını sağlıyor. Şöyle düşün, ben sana 100TL göndermek istiyorum ama kimliğimi açığa çıkarmadan göndermek istiyorum, nasıl yaparım?

    Internette sorun olarak gördüğüm ve yazılımla çözülebilecek birşey var: Merkeziyetçi web siteleri. Örneğin forumlar. Örneğin Youtube, Twitter, Linked-in.. Örneğin sahibinden, letgo. Bu merkeziyetçi siteler, herşeye sahip konumda. Sen bir içerik gönderiyorsun demi? O içerik senin değil, gönderdiğin sitenin malı artık. Sahibinden 'e ilan aç. Ürünün resmine logosunu basar, bu resim benim anlamında. Forumda konuşulması yasak konular var. Yok yanlış anlamayın, ülke yasalarına aykırı konular değil, sadece forumun kurallarına aykırı konular. Youtube yorumlarda özgür gibisin fakat orada da gönderidğin videolarda aynı keyfi kurallar uygulanıyor. YT begenmediği videolara bi bahane bularak sansür uyguluyor yani yayından kaldırıyor. Fakat bi sorun daha var: YT, diger tüm siteler gibi, kullanıcılara GSM no girmesini dayatıyor ve bunu da "sizin hesap güvenliğinizi düşünüyoruz" gerekçesine bağlıyor, yani 8 yaşındaki cocuğa kural dayatan ebeveynlik yapıyor size YT. Tüm bu bahsi geçen problemlere karşı IPFS gibi dağıtık/distributed ve E2E / Uç uça şifreli iletişim protokolleri ile çözüm geliyor. IPFS sadece bir örnek.

    Internette Youtubeta forumlarda, site sahibi tarafından "içerik silme" problemi var. Bir içerik görüyorsun, takip ediyorsun, yorum gönderiyorsun. Sonra bir bakmışsın içerik silinmiş! IPFS çözümü ile bu içerik silme tarih olacak cunku herkes ilgilendiği içeriği kendi cihazında taşıyacak / host edecek. İçeriği böyle sitelere girip textbox içinde değil, kendi kullandığın editörde düzenleyip göndereceksin; VIM, Atom, Emacs gibi editörlere eklenecek plugin ile içeriği yazıp, editör içinden göndereceksin. Mod'un teki cıkıp 10bin kişinin takip ettiği bir içeriği bi kalemde silip atamayacak.




  • Sayılarını A = X ^ Y + Z ya da A = X ^ 2 + Z şeklinde göstermenin hızlı bir yolunu bulsan dahi bu sayıların bit sayısı toplamı A'nın bit sayısı toplamından daha büyük oluyor. Özellikle çok büyük sayılarda inceleme yaparsan Z'nin bit uzunluğu neredeyse A ile aynı oluyor buna bir de X'i eklediğinde A'nın bit uzunluğundan daha fazla çıkıyor.

    Aslına bakarsan bu yöntem benim de aklıma geldi sonra bazı testler yaptım ve bunları öğrendim.

    Benim sana sıkıştırma için çok daha farklı bir önerim var. Hem zaten yukarıdaki yöntem ve diğerleri için kayan nokta ile uğraşmayıp sadece integer lar üzerinde çalışırsan daha hızlı bir sıkıştırma algoritması oluşturmuş olursun.

    Asal sayıları kullanarak sıkıştırma

    Asal sayıları kullanarak kayıpsız sıkıştırma yapabileceğiniz ya da diğer yöntemleri tekrar tekrar kulanılabilir yapan bir yol bulduğumu düşünüyorum.

    0-255 aralığında tam 54 adet asal sayı vardır. Bir byte dizisinde asal sayıya denk geldiğimizde bunu 8 bit yerine 6 bit kullanarak bu sayının asal sayı indekslerini kullanarak saklayabiliriz öyle değil mi?

    Hangi sayılar için sıkıştırma yaptığımızı saklayabileceğimiz her byte için bir bit kullanarak bir harita oluşturup bunu da veri dizisine eklemek gerekiyor.

    Bu ilk başta işe yarar gibi görünüyor fakat dosya boyutunu biraz uzatıyor ancak dosyayı LZ4 ya da Huffman gibi algoritmalar için yeniden sıkıştırılabilir bir yapıya indirgiyor.

    0-53 arası indeksler 2-251 arası asal sayılara denk geliyor fakat burada 6 bit için kullanılmayan sayılar var. (54-63). Bu 10 sayıyı da frekansı en yüksek olan ve asal olmayan 10 farklı sayıyı 6 bitte saklamak için bir fırsat oluşturabilir. Böylece daha fazla sayıyı sıkıştırmış olacağız. Bu oran %50'yi aşarsa başarılı bir sıkıştırma yapabileceğiz.

    Ayrıca bu yöntem sıkıştırılmış sayıları yeniden sıkıştırmak için bir fırsat oluşturabilir. Sizce bir byte yerine 4 ya da 8 byte lık veri blokları halinde unit ve ulong veri türleri için bir yöntem oluştursak böylece sıkıştırılmış verinin haritasını daha küçük boyuta indirgeyebiliriz, öyle değil mi?

    2 ^ 32 'den küçük 203280221 asal sayı vardır. Bu da her asal sayı için 32 bit yerine 28 bit kullanarak saklayabileceğimiz anlamına geliyor.

    Veri dizisideki asal sayıların oranına bakarak verimli bir sıkıştırma yapıp yapamayacağımızı belirleyebiliriz.

    Ben bu yöntemin etkili bir sıkıştırma yöntemi olabilmesinden ziyade sıkıştırılmış dosyaların yeniden sıkıştırılmasına olanak oluşturabilecek bir veri değişimi olabileceğini düşünüyorum.

    Sormak istiyorum asal sayıları kullanarak sıkıştırma yapabileceğimiz başka yöntemler biliyor musunuz? Çünkü asal sayıları elde etmek özellikle 2 ^ 32'nin altındaki sayılar için çok kolaylaştı. Yöntemlerimiz arasına asal sayı yöntemlerini de eklememiz gerekiyor.




  • Sap saman iyice karışmış yine.
    8 bitlik verilerle 6 bitlik asal dediğin verileri binary olarak rastgele yan yana yaz. Sonra geri çöz bakalım ?

    Değerlerimiz 5,6,9,11 olsun. (00000101, 00000110, 00001001, 00001011) 5 ve 11 asal ve indexleri sıra ile 2 ve 4 oluyor. Asallar (1,2,3,5,7,11...)
    Veri sırası diyelim ki şöyle: 6, 9, 5, 11 -> 00000110 00001001 000010 000100 -> 0000011000001001000010000100

    Çözümlemede ortaya çıkabilecek kombinasyonlar:
    00000110 00001001 000010 000100 -> 6 9 5 11
    00000110 000010 010000 10000100 -> 6 5 ? ?
    00000110 000010 01000010 000100 -> 6 5 ? 11
    000001 100000 10010000 10000100 -> ? ? ? ?
    000001 10000010 010000 10000100 -> ? ? ? ?
    000001 10000010 01000010 000100 -> ? ? ? 11

    Şimdi devam edebilirsiniz
  • Asal sayılarla sıkıştırma başlığından sonraki 3. paragrafı iyi anladınız mı? Hangi byte lar üzerinde sıkıştırma yaptığımızı her byte için 1 bit olacak şekilde sırasıyla saklıyoruz. Sıralı olarak 6 bit mi yoksa 8 bit mi okuma yapacağız bu haritaya bakıyoruz. 1 ise 6 bit okuyup sayıya karşılık gelen indeksteki asalı gerçek veri olarak alıyoruz yok eğer sırada 0 varsa 8 bit okuyup aynen yazıyoruz.

    Örneğin;

    Sayılar;

    A = [6, 9, 5, 11, 13, 23, 17, 31] = 8 * 8 = 64 Bit veri uzunluğu

    Map A = 00111111 -> 8 bit map için harcıyoruz.
    Compressed A = [6, 9, 2, 4, 5, 7, 6, 8]


    [8, 8, 6, 6, 6, 6, 6, 6 ] = 8+8+6+6+6+6+6+6 = 52 bit veri uzunluğu 8 bitte map için 60 bit veri uzunluğu elde ettik. Ancak veri boyutumuz daha uzun olsaydı 54-63. indekslerde frekansı en yüksek olan asal olmayan ilk 10 byte ı saklayacaktık. Bu da bize uzun dosyalar için belirli byte larda frekansı fazla olan sayıları da 6 bit içersinde saklama imkanı verecek. Böylece 6 bit (0-63) içerisindeki hiç bir sayıyı boşa harcamadan etkili bir sıkıştırma yapabileceğiz.

    Söylediğim gibi bu yöntem tek başına etkili bir sıkıştırma yapamaz ancak sıkıştırılmış verileri daha da sıkıştırabilmek, diğer bir deyişle tekrar tekrar sıkıştırma yapabilmenin önünü açacaktır.

    Örneğin bir veri kümesini öncelikle Huffman ya da LZ4 kullanarak sıkıştırın. Sıkıştırılmış dosyayı sonra bu yöntemle sıkıştırmayı deneyin sonra tekrar Huffman ya da LZ4 kulanarak sıkıştırabileceksiniz. Ya da yine aynı yöntemi kullanarak sıkıştırma yapmaya devam edebilirsiniz. Nereye kadar sürer deneyip görmek gerekiyor.

    Bu yönüyle dikkate değer görünüyor öyle değil mi?



    < Bu mesaj bu kişi tarafından değiştirildi ayhanarican -- 30 Aralık 2019; 16:32:6 >




  • 
Sayfa: önceki 12345
Sayfaya Git
Git
sonraki
- x
Bildirim
mesajınız kopyalandı (ctrl+v) yapıştırmak istediğiniz yere yapıştırabilirsiniz.