Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > pl.comp.programming > #31752

Re: Problemik nie całkiem teoretyczny

From bartekltg <bartekltg@gmail.com>
Newsgroups pl.comp.programming
Subject Re: Problemik nie całkiem teoretyczny
Date 2018-08-06 21:03 +0200
Organization ATMAN - ATM S.A.
Message-ID <pka61p$hd2$1@node1.news.atman.pl> (permalink)
References <pk3omv$7ir$1@news.icm.edu.pl> <a9ba32e9-42ce-4472-b49f-81d933065e78@googlegroups.com>

Show all headers | View raw


On 06.08.2018 15:13, Maciej Sobczak wrote:
>> Takie małe coś, akurat na wakacje:
> 
> Skoro wakacje, to...
> 
>> Ciąg liczb zmiennoprzecinkowych 64 bitowych powstał po pomnożeniu
>>   przez niezerową stałą ciągu liczb stałoprzecinkowych 16-bitowych.
>>   Czy istnieje prosta metoda kompresji, taka że nie znając tej
>>   stałej, można ograniczyć liczbę przesyłanych bajtów? Tzn. przy
>>   1000 liczbach przesłać (niewiele ponad) 2000 bajtów zamiast
>>   8000?
> 
> Chyba nie ma sensu szukać tego mnożnika, bo np. mając w ciągu liczby 10.0 i 20.0 nie wiemy, czy oryginałem było 1 i 2 z mnożnikiem 10.0, czy może 2 i 4 z mnożnikiem 5.0.

Tego nie, ale bez większych trudności znajdziesz mnożnik będący 
oryginalnym mnożnikiem razy największy wspolny dzielnik wszystkich
danych.

Taki mnożnik jest równie dobry do przesłania, a po drugiej stronie
i tak obchodzi nas tylko iloczyn danych i mnoznika, więc nie ma różnicy.


> Więc może wiedząc z góry, jakie jest ograniczenie na liczbę różnych wartości (16bit), warto je poukładać w kubełkach i przesyłać numery kubełków? Może się okazać, że oszczędność będzie jeszcze większa, jeśli nie wykorzystano wszystkich 2^16 różnych wartości a dodatkowym bonusem jest fakt, że to działa nawet wtedy, gdy skalowanie nie było liniowe (co obejmuje również zaokrąglenia przy skalowaniu). Oczywiście ciąg numerów kubełków można dalej kompresować niezależnie, np. RLE, jeśli spodziewamy się, że to ma sens.
> 
> Problemem jest przesłanie słownika - czyli jaka zakodowana wartość jest w każdym wykorzystanym kubełku. Pełny słownik to potencjalnie 2^16*64 bity, ale jeżeli ciąg jest długi albo jeden słownik jest wspólny dla wielu takich ciągów, to może się zamortyzować.
> 
>> Problem powstał w związku z pytaniem: czy lepiej przesyłać raw
>>   data - czy wielkości przeskalowane do fizycznych jednostek (np.
>>   miliamperów na hektar i węzeł)?
> 
> To zależy. Nie wiemy, co to za dane i jaka jest wymagana wierność transmisji. Skalowanie zmiennoprzecinkowe sugeruje, że 100% dokładność nie jest wymagana, więc może jakieś znane metody stratne (zależnie od rodzaju danych) byłyby akceptowalne. Bo po co napinać się na dokładny transfer niedokładnych danych?
> 


Da sie znacznie prościej. I liniowo.
Oczywiście trzeba wykorzystać to, że double ma znaczny zapas
precyzji w stosunku do int16_t.


pzdr
bartekltg

Back to pl.comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Problemik nie całkiem teoretyczny slawek <x.y@org.org> - 2018-08-04 10:38 +0200
  Re: Problemik nie całkiem teoretyczny Maciej Sobczak <see.my.homepage@gmail.com> - 2018-08-06 06:13 -0700
    Re: Problemik nie całkiem teoretyczny bartekltg <bartekltg@gmail.com> - 2018-08-06 21:03 +0200
      Re: Problemik nie całkiem teoretyczny slawek <x.y@org.org> - 2018-08-09 08:24 +0200
  Re: Problemik nie całkiem teoretyczny Wojciech Muła <wojtek.mula@gmail.com> - 2018-08-06 13:23 -0700

csiph-web