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: 2 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)
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 >
|
Tabi ki lisanslanabilir. Adına da "Yellenme Metodu" derseniz mükemmel olur. Körler sağırlar birbirini ağırlar misali seviye epey bir aşağıda indi yine. SEO19; sen önce şu belirttiğim "bit derinliği" mevzusunu bir öğren. ayhanarican sen de aynen devam et. Çünkü bu yazdığın basit şeyleri senden başka kimse düşünmemiş, aklına gelmemiş, uygulamaya dökmemiş, sonuçlarını da görmemiştir inan! Daha en temel teknik bilgilerden yoksun 2 kişi... Tabi tanışmıyorlarsa (?) |
< Bu mesaj bu kişi tarafından değiştirildi Stack -- 1 Ocak 2020; 11:35:36 >
|
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
|
itiraz edenler zor olduğu için değil bunun fiziksel olarak imkansız olduğu için itiraz ediyor 1KB lık örnek dosyamız olsun bu dosyanın toplam olası kombinasyonu 2^(1024 * 8) yapar. elimizde her biri 1KB lık 2^(1024 * 8) tane dosya olsun, her dosyanın içeriği bir birinden farklı olsun (yani olabilecek tüm kombinasyonlar) her birini 1/8 oranında sıkıştırma yapmak demek, olası kombinasyonu 2^(1024 * 7) yapmak demek. şimdi 2^(1024 * 7) kombinasyonu 2^(1024 * 8) kombinasyona çevir bakalım nasıl olacak. yapamazsın çünkü dosyaların 8 de biri aynı bitsel değerlere sahip. |
< Bu mesaj bu kişi tarafından değiştirildi Guest-4D62BFE91 -- 1 Ocak 2020; 17:12:57 >
Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @SEO19 @ayhanarican
var sqrt = Math.Pow(Math.E, BigInteger.Log(bigNumber) / 2); var startNumber = Convert.ToUInt64(sqrt); BigIteger.Log() yerine Math.Log da kullanılabilir. Şu kodu incelersen anlayacaksın. X ^ 2 + D yöntemini kullanıyoruz. Sadece bu yöntemi kullanmak istersek. Burada X'i hep asal seçip X'in asal indeksini saklarsak X için 13 bit, D için de 17 bit kullanabiliriz. D bu durumda en fazla 131071 olabilir. Eğer rastgele seçilmiş 4 byte lık N sayının %50'sinden fazlasını bu son yöntemde gösterebilirsen ki - bu olasılık hesaplanabilir - kesin bir sıkıştırma algoritması üretmiş oluruz. Şu kodu incele anlayacaksın. https://dotnetfiddle.net/m1RE5W |
1KB'da 2 ^ 1024 * 8 kombinasyon olabilir. 1KB ile 0 - (2 ^ 8192) - 1 arasındaki sayıları temsil edebilirsiniz. Böyle büyüklükte bir sayıyı ifade etmek için 0 - (2 ^ 8192) - 1 arasındaki bütün asalların bir db'sini oluşturduysan ya da asallar için bir formül bulunursa ki - bulundu - kendisinden küçük sayıya en yakın asalın indeksi ve bu sayıdan farkını saklarsan ciddi oranda sıkıştırmış olursun. Bu yöntem henüz bu aralık için asallarla çalışmanın donanımsal zorluklarından dolayı uygulanamıyor fakat çok yaknda uygulamaya alınacaktır. |
< Bu mesaj bu kişi tarafından değiştirildi ayhanarican -- 1 Ocak 2020; 18:22:45 >
Bu mesaja 1 cevap geldi.
|
bana işlemin nasıl yapılacağından bahsetme 2^(1024 * 7) kombinasyonu 2^(1024 * 8) kombinasyona nasıl çevireceksin onu söyle vahiymi gelecek? 1/8 oranında sıkıştırmadan sonra dosyaların 8 de biri aynı veriye sahip olacak aynı veriden farklı kombinasyon çıkma işi nasıl olacak? |
< Bu mesaj bu kişi tarafından değiştirildi Guest-4D62BFE91 -- 1 Ocak 2020; 18:8:57 >
Bu mesajda bahsedilenler: @ayhanarican
| valla konuya yazsammı yazmasammı derken belki faydam olur birilerini bu boş hayallerden kurtarırım diye düşündüüm yazdım :) dediğin gibi çokmu zor bir dil öğrenmek bu gibi algoritmaları yazmak için dilin tamamını da öğrenmene gerek yok harcayacağın zaman 12 saati geçmez. |
< Bu mesaj bu kişi tarafından değiştirildi Guest-4D62BFE91 -- 1 Ocak 2020; 19:38:42 >
Bu mesajda bahsedilenler: @Stack
|
Bunlardan piyasada çok var Determinist. İşleri güçleri laf üretmek. Okudukları, gördükleri bir kaç şeyle adam olduk sanarlar. Ben Entropi diyorum, Kolmogorov Karmaşası diyorum tık yok. Adam işlem yaparken onu seçiyor bunu seçiyor, işine geldiği gibi gidiyor. Performansı geçtik, ulan bunun bir de kayıpsız geri çözümlemesi olacak. Yok şuna bakıyor yok buna bakıyor, daha ettiği masrafı düşünemiyor. Neyse gösterecek uygulamasını ve kayıpsız çözümünü Excel de bize. Yoksa biz ona gösterecez artık  |
Bu mesaja 1 cevap geldi.
|
Aşufte için özürümü sunarım demedim sayın. Ya da sen benim huyumu bilmem ne yapmış ol, falan. Şimdi ispat niyetine bir iki kelâm edeyim. 1. Asal sayılarla sıkıştırma yöntemi a. 1 Byte lık asal sıkıştırma b. 4 byte lık asal sıkıştırma 2. X ^ 2 + D -> Tam kare uzaklığı ile gösterim. X asal seçiyoruz ve 13 bit D ise 17 bit max: 131071 1. a. 0-255 arasında 54 adet asal sayı vardır. Bu rastgele seçilen N sayının yaklaşık %21 oranında asal byte içermesi anlamına gelir. Tüm byte lara bakıyoruz asal ise 6 bit kullanarak 0-53 arasında bir sayıyla indeksleri saklıyoruz. Değilse aynen 8 bit olarak yazıyoruz. Elbette sıkıştırma yapıp yapmadığımızla ilgili olarak bir bit olmak üzere harita oluşturuyoruz ve bunu da verilere ekliyoruz. Şimdi kullanılmayan 54-63 arası indeksler içinde yeni bir fırsat oluşuyor. Tüm byte ların frekanslarını çıkarıyoruz ve frekansı en yüksek asal olmayan 10 byte ı seçiyoruz. Sayı asal olmasa da kodlarken harita da bir gösterip bu frekans tablosundaki bu 10 sayıdan birine denk gelince 0-9 a karşılık 54-63 olarak bunu kodluyoruz. Böylece etkili bir sıkıştırma oluşturmuş oluyoruz. Etkili bir sıkıştırma olabilmesi için en az kaç byte ın asal olması gerektiğini ya da frekans tablosundaki ilk 10 sayının dosyanın en az % kaçına denk gelmesi gerektiğini hesaplayabiliriz. Bunu size bırakıyorum. 1. b. Sayıları 4'er byte lık bloklar haline getiriyoruz asal her sayıyı indeksiyle 28 bitte saklıyoruz çünkü bu aralıkta 203 milyon asal var. Yine dosya içerisindeki asal sayı oranı kritik önem taşıyor? En az kaç olmalı ki oluşturacağımız 1 bitlik haritayı içermesine rağmen kazanç sağlayabilsin bunu size soruyorum? Yine (2 ^ 28) - (bu aralıktaki asal sayısı - yaklaşık 203 milyon) ?? burada frekansı yüksek olan byte dizilerini saklamak için kullanabiliriz. 2 . X ^ 2 + D X'i daima asal seçiyoruz ve 65.5 binin üzerine asal indeksleri kullanarak 13 bit ile rahatlıkla ulaşıyoruz. D için 17 bit (131071) ayırıyoruz. Şimdi soruyorum. Rastgele seçilen 4 byte lık N sayının % kaçını bu gösterimle sağlayabiliriz. Buna siz cevap verin. N / 2 den ne kadar fazla olabilir. |
Bu mesaja 1 cevap geldi.
|
huyunu sikerim için özrümü sunarım demedim say. sadece şu kısımda kar yerine zarar ediyorsun asalsayıları indekslerken + 1 bit sıkıştırma yapıldımı yapılmadımı bilgisi ekliyorsun yani %21, 7 bit kullanacaksın %79, 9 bit kullanacaksın. gerisini okumadım. |
Bu mesajda bahsedilenler: @ayhanarican
| Bu bit dizisinde bol sıfır olduğu için Huffman ya da LZ ile ekstra sıkıştırabiliyoruz. Sen oarayı kafana takma orada veri boyutu en az %70 kısalacak. Gerisini okumamak düşük zeka belirtisidir. Çözüme yönelik düşün sorunları birlikte çözelim. |
Bu mesaja 1 cevap geldi.
| konunun buraya varacağı en başından belliydi. göstermeye çalıştığım şey bunun imkansız olduğuna dair somut delildi. neyse son mesajım olsun zaman israfına gerek yok. |
Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @ayhanarican
Bit haritası veriyi 1/8 oranında artırırken asal byte lar 1 / 20 oranında azaltacak. öte yandan bit haritası sıkıştırıldığında 1 / 24 artacak ve 1 / 20 azalacak nihayetinde 1 / 24 artıp 1 / 20 azalan bir veri kısalacaktır. Frekans tablosuna ve faydasına hiç girmiyorum. Dizilime bakılmaksızın her hangi bir veri dizisini kısaltacak mükemmel bir yöntemdir. Lisanslanması gerekir. 1 + (1 / 24) - (1 / 20) = %99,1 sıkıştırma oranıyla ve defalarca kullanılabilmesi ile yeni neslin sıkıştırma formatları arasında yerini alabilir. :( Bu kadar laf işittiğime değdi mi? |
< Bu mesaj bu kişi tarafından değiştirildi ayhanarican -- 1 Ocak 2020; 22:16:49 >
Bu mesaja 1 cevap geldi.
| Jetonun köşelerini iyi zımparalayınca kimseden ses çıkmıyor. :) |
|
hala defalarca kullanmaktan bahsediyorsun, bu bir hayal anla artık. bunu sana daha sade bir şekilde anlatabilirdim ama harcayacağım zamana değmezsin. sıkıştırma algoritman o kadar iyiki çıktı boyutu orijinal boyuttan büyük oluyor bunu da LZ ile ekstra küçültmeye çalışıyorsun. |
< Bu mesaj bu kişi tarafından değiştirildi Guest-4D62BFE91 -- 1 Ocak 2020; 21:53:43 >
Bu mesaja 1 cevap geldi.
Bu mesajda bahsedilenler: @ayhanarican
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 >