> 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