eGospodarka.pl
wiadomość od św. Mikołaja

eGospodarka.plGrupypl.comp.programming › Re: Problemik nie całkiem teoretyczny
Ilość wypowiedzi w tym wątku: 2

  • 1. Data: 2018-08-06 15:13:20
    Temat: Re: Problemik nie całkiem teoretyczny
    Od: Maciej Sobczak <s...@g...com>

    > 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


  • 2. Data: 2018-08-06 21:03:20
    Temat: Re: Problemik nie całkiem teoretyczny
    Od: bartekltg <b...@g...com>

    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

strony : [ 1 ]



Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo:

Ok, rozumiem Strona wykorzystuje pliki cookies w celu prawidłowego jej działania oraz korzystania z narzędzi analitycznych, reklamowych, marketingowych i społecznościowych. Szczegóły znajdują się w Polityce Prywatności. Dalsze korzystanie ze strony oznacza, że zgadzasz się na ich użycie. Jeśli nie chcesz, aby pliki cookies były zapisywane w pamięci Twojego urządzenia, możesz to zmienić za pomocą ustawień przeglądarki.