eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingPotyczki › Re: Potyczki
  • Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
    atman.pl!news.supermedia.pl!news.nask.pl!news.nask.org.pl!news.internetia.pl!ne
    wsfeed.neostrada.pl!unt-exc-02.news.neostrada.pl!unt-spo-a-02.news.neostrada.pl
    !news.neostrada.pl.POSTED!not-for-mail
    Newsgroups: pl.comp.programming
    From: PK <P...@n...com>
    Subject: Re: Potyczki
    References: <k8frhm$5pg$1@node1.news.atman.pl>
    <50abbc9e$0$1214$65785112@news.neostrada.pl>
    <k8p9ei$h43$1@mx1.internetia.pl> <s...@n...notb-home>
    <50b0bf80$0$1213$65785112@news.neostrada.pl>
    <s...@n...notb-home>
    <50b0cf1f$0$1211$65785112@news.neostrada.pl>
    Reply-To: PK <P...@n...com>
    User-Agent: slrn/pre1.0.0-18 (Linux)
    Mime-Version: 1.0
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: 8bit
    Message-ID: <s...@n...notb-home>
    Date: 24 Nov 2012 14:18:37 GMT
    Lines: 46
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 83.31.143.107
    X-Trace: 1353766717 unt-rea-a-02.news.neostrada.pl 1313 83.31.143.107:4566
    X-Complaints-To: a...@n...neostrada.pl
    Xref: news-archive.icm.edu.pl pl.comp.programming:201196
    [ ukryj nagłówki ]

    On 2012-11-24, slawek <s...@h...pl> wrote:
    >
    > Użytkownik "PK" <P...@n...com> napisał w wiadomości grup
    > dyskusyjnych:s...@n...notb-home.
    ..
    >> o klasę problemów i klasę złożoności. W szczególności: rozwiązanie
    >> Twojego problemu będzie miało złożoność nie mniejszą niż sortowanie,
    >
    > Jeżeli będziemy upierali się aby porównywać dane - oczywiście. A czy to na
    > pewno trzeba robić? Ot, pytanie!

    Tak. Dominanta to najczęściej występująca wartość w zbiorze. To oznacza,
    że trzeba porównywać elementy (to tak z definicji).

    Ale oczywiście można wykombinować podejście przybliżone. Masz ten stream
    wartości. Bez problemu możesz w swoim RAM obsługiwać te M-krotki.
    Wymyśl dużo różnych funkcji mających M argumentów. Obliczasz je
    wszystkie na ostatniej M-krotce i przesuwasz okno o 1. Możesz
    budować histogramy wartości (zmieścisz je w pamięci), a na końcu
    odgadnąć na ich podstawie dane wejściowe (tzn. zbiór możliwości,
    który - przy odrobinie szczęścia - będzie zawierał jakieś podobne
    elementy). Jeśli Twój "stream" to np sygnał elektryczny i szukasz
    najbardziej popularnego impulsu, to możesz próbować dopasowywać
    jakieś patterny. To jest podejście wyciągnięte wprost z HFT, FX i AT,
    czyli skrótów, które tak zbulwersowały część dyskutantów.

    Ale tak naprawdę najlepiej byłoby, gdybyś podszedł do tego jak fizyk,
    a nie programista. Twoje dane to pewnie wynik jakiegoś doświadczenia.
    Powinieneś ogarnąc teorię stojącą za tym procesem i wyciągnąć z tego
    maksymalnie dużo (na kartce czy jak wolisz: e-notesie). W najlepszym
    wypadku skończysz z dobrym modelem. W najgorszym: z filtrami, które
    istotnie zmniejszą Ci rozmiar problemu.
    Tak naprawdę Twój stosunek ilości danych do dostępnego RAMu nie jest
    w żaden sposób imponujący. LHC generuje kilkaset GB/s. Podstawowe
    filtry obcinają 99.9%. I nie jest to efekt żadnej zajebistej algorytmiki
    tylko lat skrupulatnego rzeźbienia w fizyce.

    Ponadto przypominam, że jeśli są to dane empiryczne, a nie złośliwie
    generowane, to możesz estymować na ich podzbiorze. Możesz budować
    i kalibrować model na np. połowie tego streamu i potem puścić go
    na reszcie.

    Generalnie możesz zrobić dużo rzeczy mądrzejszych niż wymyślanie
    algorytmu na siłę (szczególnie jeśli taki algorytm nie istnieje).

    pozdrawiam,
    PK

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

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: