Teknoloji Haberleri
Aşağı Git
Tüm Forumlar
Web Tasarım - Programlama
Yazılım Geliştirme
Projeler
Histogram Based, Real Time Lossless Data Compression Algorithm λ∈[(ArgMax⇔>∀xω1)
Bu konudaki kullanıcılar: 3 misafir, 2 mobil kullanıcı
148
Cevap 13533
Tıklama 0
Öne Çıkarma
Cevap 13533
Tıklama 0
Öne Çıkarma
-
Cevap: Histogram Based, Real Time Lossless Data Compression Algorithm λ∈[(ArgMax⇔>∀xω1) (3. sayfa)
|
İ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 >
< Bu ileti mobil sürüm kullanılarak atıldı > Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @Stack
|
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  |
Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @Communist
| 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. |
< Bu ileti mobil sürüm kullanılarak atıldı >
Bu mesajda bahsedilenler: @Stack
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. |
< Bu ileti mobil sürüm kullanılarak atıldı >
Bu mesajda bahsedilenler: @SEO19
|
@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: < Resime gitmek için tıklayın > |
Bu mesajda bahsedilenler: @Communist
| 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. |
< Bu ileti mini sürüm kullanılarak atıldı > Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @SEO19
|
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 >
Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @vonderplanitz
|
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. |
Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @Stack
|
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 |
Bu mesajda bahsedilenler: @vonderplanitz
|
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 >
|
Boş konuşuyorsun arkadaşım. Daha çok yenisin bu işlerde belli. Sen byte başına 1 bit harcayarak nereye varacağını sanıyorsun. Hangi veriyi düzenleyip Huff/LZ ile kullanıyorsun. Aksine Entropi nin içine edersin. Entropi nedir bilir misin sen? Bir bak biraz araştır sonra buradan "Elbette biliyorum" de tamam mı? Huffman byte lar ile işlem yapıp bit verir. LZ serisi ise tamamen byte lar ile çalışır ve yine byte verir. Biraz ciddi olup bu zırvaladığın şeyleri ufak bir uygulama ile gösterebilirsin. Ancak sonucunu şimdiden söyleyebilirim ama sen yine de dene gör. "Olacaktır, açacaktır, yapacaktır" sökmez bu işlerde. Amatör olduğun buradan belli. Hadi bakalım bekliyoruz uygulamayı yiğido |
< Bu mesaj bu kişi tarafından değiştirildi Stack -- 30 Aralık 2019; 20:47:30 >
Aydınlandığına göre ışıt ortalığı ortağaam  Arkadaşın ve senin bir şey farkettiği falan yok. Bu konudaki tanıdığım çoğu kimse gibi eksik bilgilerle sadece konuşuyorsunuz. Ayrıca 2 bitle 4 renk temsil edilebilir (00,01,10,11). 1 bit le ise 2 renk (0,1). Öncelikle bunu karıştırıyorsun ! Bir de kayıplı (jpeg) ve kayıpsız formatları (bmp, tiff) da karıştırıp yanlış yorumlar yapıyorsun ! Bunları aynı cümlede kullanmak bile teknik olarak doğru değildir. Wikipedia : "Kolmogorov Complexity" teoremi comp.compression FAQ belgesindeki pek çok meydan okuma için temel teşkil eder. Bu teoremin varlığına rağmen zaman zaman bazı kişiler (bunlara çatlak denir) herhangi bir veriyi kayıpsız olarak büyük ölçüde sıkıştırabilen algoritmalar geliştirdiklerini iddia ederler. |
Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @SEO19
|
Her sayının mutlaka daha kısa bir gösterimi vardır. 1. Bu x ^ y + z olabileceği gibi 2. x ^ 2 + z olabilir, ya da 3. p bir prime olmak üzere p + d olarak gösterilebilir ve yalnızca p'nin indeksi ve d saklanır. Bütün sayıları kapsayacak tek bir gösterim yoktur ancak her sayıyı daha kısa gösterebileceğiniz bir yol mutlaka vardır. Örneğin işe yarar 256 adet yöntem bulup bununla 128 ya da 256 bitlik sayıları daha kısa gösterebilirsiniz. Bu yöntemle ciddi oranda rastgele oluşturulmuş byte dizileri de dahil hemen her türlü veriyi sıkıştırabilirsiniz. Hiç bir şey yapamıyorsanız özellikle 1KB dosyalar için byte dizisinin tamamını büyük bir integer sayı olarak ele alıp bu sayıdan küçük ilk primeyi bulup sayıyı p + d olarak gösterip p'nin indeksini ve d'yi sakladığınızda çok ciddi oranda sıkıştırma uygulayabilirsiniz. Bunu büyük dosyalarda her bir KB için tekrarlayabilirsiniz. Bir N sayısına kadar yaklaşık N / log(N) kadar asal sayı vardır. Bu da size sıkıştırma oranı hakkında daha fazla bilgi verebilir. Bir N sayısına kadar kaç adet prime olduğunu daha kesin ifade edebilen formüller vardır. Zira bu sayıyı bulduğunuzda bir n sayısından küçük kaç adet prime olduğu prime indeksiyle ilgilidir. Çok büyük asal sayı veritabanları kullanılmaya başlandığında bu yöntemler hayatımıza girecekler. Her byte dizisini 0 byte a indirgeyen farklı bir algoritma bulunabilir fakat bir algoritmadan bahsediyorsak bırakın her byte dizisini 0 byte a indirmeyi %10 başarılı bile olabiliyorsa bu muhteşem bir şeydir. Ancak bu çok mümkün değildir. En kötü ihtimalle biraz yavaş çalışacak olsa da en küçük kareler yöntemi ile byte dizisini oluşturabilecek parçalı ya da generic bir fonksiyon ya da algoritma oluşturup bunu saklayabilirsiniz ve mutlaka daha az yer kaplayacaktır. |
< Bu mesaj bu kişi tarafından değiştirildi ayhanarican -- 1 Ocak 2020; 9:44:58 >
|
Not edin efsane yöntemi hemen açıklıyorum. Birileri benim Huffman'dan ya da bir konudaki ilk çözümü bulan kişilerden daha zeki olamayacağımı ya da bunu başaramayacağımı imâ etmiş. Bir konuyu, deneyerek öğrenmeye hevesli birinden daha iyi bilemezsiniz. Bilebileceğini iddia eden aptaldır ve her konuya negatif yaklaşan bir pesimisttir hepsi bu! 4 bytelık veri bloklarını diziliminden bağımsız olarak sıkıştırmayı deneyeceğiz. İki bitlik işlem kodları 00 - Sıkıştırma yok 01 - 2 ^ N + D ifadesi -> Burda N maksimum 5 bit ve D ise 23 bittir. Toplam 28 bit 02 - X ^ 2 + D iadesi -> Burada X, 2 byte (16 bit), D ise 12 bittir. Toplam 28 bit 03 - Pi - Prime index -> Sayı asalsa prime indeksi saklıyoruz. 2 ^ 32 'nin altında 203280221 asal sayı vardır ve max 28 bitte saklanabilir. Şimdilik max 2 GB dosyalar üzerinde çalışacağız. Tüm dosya 4 bytelık veri blokları şeklinde bir array a alınır. Sayı asalsa direk 3. yöntem kullanılır değilse 1. ve 2.yöntemlerden hangisi ile daha az bitle temsil edilebiliyorsa o seçilir. Eğer sıkıştırılan 4 bytelık sayıların oranı %50'yi aşarsa başarılı bir sıkıştırma yapılabilir. Aşamazsa sıkıştırma olmaz. Örneğin 3. seçenek için 4 bytelık veri dizisinde her defasında sayıların yaklaşık %10'u asal sayı çıkıyor. Bu çalıştığımız aralıktaki N / log(N) ile doğrudan ilişkilidir. Kalanın %40'ından daha fazlasını 1. ve 2. yöntemle sıkıştırabilirseniz başarılı bir sıkıştırma gerçekleştirilmiş olur. İşin güzel tarafı ilk seferinde yüksek oranlı bir sıkıştırma yapamasak da tekrar tekrar uygulayarak sıkıştırma oranını yükseltebiliriz. Tekrar tekrar uygulanabilmesi dikkate değerdir. Yine uygulanan yöntemde, haritayı 2 bit olarak saklamadan hangi yöntemin seçileceği ile ilgili kurallar oluşturulursa bu iki bitlik harita kayıt edilmeden de yöntem kullanılabilir hale getirilebilir. okunan sonraki 28 bit ve 32 bit karşılaştıtılır 32 bit okunup sıkıştırma yapılabiliyorsa sıkıştırma var şeklinde yorumlanır. Böylece yöntemler tahmin edilerek tahmin konusunda kararsız kalındığında bit haritasına işlenir böylece daha tasarruflu ve efektif bir algoritma hazırlanmış olur. Samimi dostane ve yapıcı sorularınıza açığım. Konuyu daha fazla detaylandırabilirim fakat 3 kuruşluk pesimist ağzınızı benden uzak tutun. |
< Bu mesaj bu kişi tarafından değiştirildi ayhanarican -- 1 Ocak 2020; 13:47:14 >
| düşündüklerini yazmaya başlasalar jeton düşecek ama nedense denemiyorlar. |
Bu mesajda bahsedilenler: @Stack
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 >
Bu mesajda bahsedilenler: @SEO19