> 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.
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?

--
Maciej Sobczak * http://www.inspirel.com

do góry

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

do góry