eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingWyszukiwanie › Re: Wyszukiwanie
  • X-Received: by 10.182.46.133 with SMTP id v5mr144222obm.9.1462529531968; Fri, 06 May
    2016 03:12:11 -0700 (PDT)
    X-Received: by 10.182.46.133 with SMTP id v5mr144222obm.9.1462529531968; Fri, 06 May
    2016 03:12:11 -0700 (PDT)
    Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed2.atman.pl!newsfeed.atman.pl!go
    blin1!goblin.stu.neva.ru!sq19no3181442igc.0!news-out.google.com!k10ni235igv.0!n
    ntp.google.com!sq19no3181440igc.0!postnews.google.com!glegroupsg2000goo.googleg
    roups.com!not-for-mail
    Newsgroups: pl.comp.programming
    Date: Fri, 6 May 2016 03:12:11 -0700 (PDT)
    In-Reply-To: <5...@g...com>
    Complaints-To: g...@g...com
    Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=195.66.98.6;
    posting-account=VFwkXwoAAADdT4-lLKRZrMYkTjizGoyn
    NNTP-Posting-Host: 195.66.98.6
    References: <6...@g...com>
    <b...@g...com>
    <5...@g...com>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <b...@g...com>
    Subject: Re: Wyszukiwanie
    From: Wojciech Muła <w...@g...com>
    Injection-Date: Fri, 06 May 2016 10:12:12 +0000
    Content-Type: text/plain; charset=ISO-8859-2
    Content-Transfer-Encoding: quoted-printable
    Xref: news-archive.icm.edu.pl pl.comp.programming:209352
    [ ukryj nagłówki ]

    On Monday, May 2, 2016 at 8:07:19 AM UTC+2, M.M. wrote:
    > > Po pierwsze zapomnij o wyszukiwaniu interpolacyjnym. Dla
    > > niejednostajnych rozkładów danych jest wolniejsze niż
    > > binarne.
    > Zapominam o dosłownym stosowaniu wyszukiwania interpolacyjnego. Ciekawy
    > jednak jestem jakby działało 'wyszukiwanie adaptatywne' - tę nazwę
    > wymyśliłem w tej chwili. Jaki algorytm mógłby się kryć za wyszukiwaniem
    > adaptatywnym? Byłaby to kombinacja wyszukiwania binarnego i interpolacyjnego.
    > Wyszukiwanie binarne dzieli zbiór (prawie) na pół (N/2,N/2).
    > Interpolacyjne może nawet podzielić zbiór na (N-1,1). Wystarczyłoby dać
    > jakieś ograniczenie M z przedziału np. od 0.1 do 0.9. Następnie
    > zbiór byłby dzielony na ( N*M , N*(1-M) ). Pozostaje tylko ustalić
    > optymalną wartość M. Ilość wyszukiwań dla takiego algorytmu wahałaby się
    > pomiędzy Log2N a Log10N.

    No tak, tylko wtedy wchodzą obliczenia zmiennoprzecinkowe i może
    się okazać, że nie będzie szybciej (w czasie, bo asymptotycznie to może :) ).

    Pomyśl może o jakiś drzewach samoorganizujących, które nie przechowywałyby
    jednak wszystkich elementów, ale podprzedziały (całe tablice, mówiąc
    obrazowo). Takie drzewo byłoby płytkie, więc nie byłoby dużego narzutu
    na dereferencje wskaźników. I po dojściu do liścia odpalałbyś już jakieś
    wyszukiwanie w tablicy.

    > > Ja bym został przy binarnym, raczej w ogólnym przypadku
    > > szybciej tego nie zrobisz. Masz przy 1 milionie elementów
    > > 20 porównań, naprawdę ciężko to przebić. Ale chętnie
    > > bym się mylił w tym miejscu. :)
    > W ogólnym pewnie się nie mylisz. Ale jakby z każdym wyszukiwaniem
    > coraz lepiej dopasować wartość M, to może dla niektórych przypadków
    > dałoby się zejść do 6 wyszukiwań dla miliona?

    Twoje pytanie zainspirowało mnie do mieszanego podejścia
    wyszukiwania binarnego i liniowego. Jak w binarnym dochodzimy
    do wąskiego przedziału (kilka, kilkanaście elementów), to
    przechodzimy na liniowe. Liczba odczytów z pamięci będzie taka
    raczej taka sama, za to liczba operacji mniejsza. I to daje
    dobre efekty, tu masz kod:

    https://github.com/WojciechMula/simd-search/blob/mas
    ter/binsearch-linear.cpp

    w.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

  • 07.05.16 08:48 M.M.
  • 07.05.16 16:10 M.M.

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: