W dniu wtorek, 15 stycznia 2013 12:43:42 UTC+1 użytkownik Michoo napisał:
> On 15.01.2013 12:39, firr kenobi wrote:
>
> >> to indeksowanie byloby lepszym wyjsciem niz
>
> >> szybki algorytm wyszukiwania. :-? Za duzo
>
> >>
>
> >
>
> > swoja droga np taki algorytm wyszukiwania w acrobet reader nie jest za szybki -
pliki po 5 czy 15 MB a na wyszukiwania sie czeka (o ile pamietam)
>
>
>
> A algorytm wyszukiwania w kpdf albo okular jest wyjątkowo szybki -
>
> wyszukiwanie w standardzie C++ działa płynnie w trakcie pisania. To jest
>
> pewnie różnica algorytmu naiwnego vs. algorytmu dedykowanego. (+ pewnie
>
> jakieś cache danych tekstowych)
>

wydaje mi sie ze prymitywny po buforze ze
znakami dzialalby szybciej niz to co ja pamietam z acrobat reader - pewnie raczej
dane tekstowe sa trzymane wewnetrznie w bardziej skomplikowanej postaci i to skakanie
po niech spowalnia

do góry

On 15.01.2013 12:47, firr kenobi wrote:
>
> najpewniej wersja z ktora ja bym na poczatku kombinował to np cos takiego:
[...]
> wypadku - nieststy trzebs ie troche pokombinowac - moze sa tez jakies lepsze
pomysly

Opisałeś właśnie ideę leżącą u podstaw KMP czy (w bardziej rozwiniętej
wersji w Boyera/Moore'a) - w pierwszym kroku liczy się wektor służący
ustaleniu gdzie szukać dalej w momencie gdy nie uda nam się dopasowanie.

--
Pozdrawiam
Michoo

do góry

W dniu wtorek, 15 stycznia 2013 12:58:52 UTC+1 użytkownik Michoo napisał:
> On 15.01.2013 12:47, firr kenobi wrote:
>
> >
>
> > najpewniej wersja z ktora ja bym na poczatku kombinował to np cos takiego:
>
> [...]
>
> > wypadku - nieststy trzebs ie troche pokombinowac - moze sa tez jakies lepsze
pomysly
>
>
>
> Opisałeś właśnie ideę leżącą u podstaw KMP czy (w bardziej rozwiniętej
>
> wersji w Boyera/Moore'a) - w pierwszym kroku liczy się wektor służący
>
> ustaleniu gdzie szukać dalej w momencie gdy nie uda nam się dopasowanie.
>
>

no to jak nie ma nic lepszego (bo moze cos jest) to tak nalezy zrobic - kwestia tylko

jak napisac optymalnego dynamicznego 'switcha'
ktory by jak najszybciej odrzucał kolejne 'pozycje' - nad wyoptymalizowaniem tego
trzebeby sie troche nagłowkowac, najszybsze bybylo pewnie gdyby sprowadzic do
dynamicznie budowanego (na podstawie ciagu) drzewa warunkow
-if - ale skoro to nie, to nie wiem

do góry

W dniu wtorek, 15 stycznia 2013 13:14:45 UTC+1 użytkownik firr kenobi napisał:
> W dniu wtorek, 15 stycznia 2013 12:58:52 UTC+1 użytkownik Michoo napisał:
>
> > On 15.01.2013 12:47, firr kenobi wrote:
>
> >
>
> > >
>
> >
>
> > > najpewniej wersja z ktora ja bym na poczatku kombinował to np cos takiego:
>
> >
>
> > [...]
>
> >
>
> > > wypadku - nieststy trzebs ie troche pokombinowac - moze sa tez jakies lepsze
pomysly
>
> >
>
> >
>
> >
>
> > Opisałeś właśnie ideę leżącą u podstaw KMP czy (w bardziej rozwiniętej
>
> >
>
> > wersji w Boyera/Moore'a) - w pierwszym kroku liczy się wektor służący
>
> >
>
> > ustaleniu gdzie szukać dalej w momencie gdy nie uda nam się dopasowanie.
>
> >
>
> >
>
>
>
> no to jak nie ma nic lepszego (bo moze cos jest) to tak nalezy zrobic - kwestia
tylko
>
> jak napisac optymalnego dynamicznego 'switcha'
> ktory by jak najszybciej odrzucał kolejne 'pozycje' - nad wyoptymalizowaniem tego
trzebeby sie troche nagłowkowac, najszybsze bybylo pewnie gdyby sprowadzic do
dynamicznie

w c najprawdopodobniej zbudowac na podstawie ciagu tabele od kazdej litery alfabetu z
iloscia wystapien litery w podciagu np
t['x']=0; t['d']=2; i uzyc tego jako pierwsze
kryterium odrzucania a dla tych co przejda
zrobic ew dalsze porownania z przyleglymi
9albo w takim samym drzewkowym stylu albo jak sie nie chce pisac zwykle strcomp z
offsetem
- pewnie lepsze bo wychodzi na to samo)

Choc moze byc jakas ew moze jakas szybsza metoda

do góry

a jaka postac zbiornika danych do przetrzymywania tekstu? ja pewnie kombinawalbym z
lista chunkow z tekstem ale dosyc duzych, moze okolo 1MB kazdy

do góry

W dniu wtorek, 15 stycznia 2013 13:43:18 UTC+1 użytkownik firr kenobi napisał:
> a jaka postac zbiornika danych do przetrzymywania tekstu? ja pewnie kombinawalbym z
lista chunkow z tekstem ale dosyc duzych, moze okolo 1MB kazdy

moze jednak za duze, moze lista linijek? trudno powiedziec :\

do góry

W dniu 2013-01-15 13:14, firr kenobi pisze:
> W dniu wtorek, 15 stycznia 2013 12:58:52 UTC+1 użytkownik Michoo napisał:
>> On 15.01.2013 12:47, firr kenobi wrote:
>>
>>>
>>
>>> najpewniej wersja z ktora ja bym na poczatku kombinował to np cos takiego:
>>
>> [...]
>>
>>> wypadku - nieststy trzebs ie troche pokombinowac - moze sa tez jakies lepsze
pomysly
>>
>>
>>
>> Opisałeś właśnie ideę leżącą u podstaw KMP czy (w bardziej rozwiniętej
>>
>> wersji w Boyera/Moore'a) - w pierwszym kroku liczy się wektor służący
>>
>> ustaleniu gdzie szukać dalej w momencie gdy nie uda nam się dopasowanie.
>>
>>
>
> no to jak nie ma nic lepszego (bo moze cos jest) to tak nalezy zrobic - kwestia
tylko
> jak napisac optymalnego dynamicznego 'switcha'
> ktory by jak najszybciej odrzucał kolejne 'pozycje' - nad wyoptymalizowaniem tego
trzebeby sie troche nagłowkowac, najszybsze bybylo pewnie gdyby sprowadzic do
dynamicznie budowanego (na podstawie ciagu) drzewa warunkow
> -if - ale skoro to nie, to nie wiem


Piszesz o tym od tygodnia. Teraz w ciągu godziny
wysłałeś 4 posty, wiec widać nad tym siedzisz i myślisz.
W tym czasie zdążyłbyś przeanalizować podesłane linki.

Np w KMP masz wprost napisane, o ile i jak przeskakiwać.

Ale jeśli chodzi o prostotę, nadal zalecam karpa-rabina.

pzdr
bartekltg

do góry

identyfikator to inny kolega, nie ja, ;)
co do mnie (grfr) to przygodnie sie
zinteresowalem i nie mam czasu czytac
wiki czy praktycznie czegokolwiek
innego niz same posty ;\ (tak ze jak ktos
stresci co wyczytal w google i co jest
lepsze od czegos to ok i mozna pogadac,
ale pod linki nie zagladam z braku czasu)

do góry

W dniu 2013-01-15 18:09, firr kenobi pisze:
>
> identyfikator to inny kolega, nie ja, ;)

Aj, racja.

> co do mnie (grfr) to przygodnie sie
> zinteresowalem i nie mam czasu czytac
> wiki czy praktycznie czegokolwiek
> innego niz same posty ;\ (tak ze jak ktos

Przeczytałbyś w 20 minut i już byś wszytko wiedział,
wikipedia jest w przypadku prostych rzeczy naprawdę
wydajniejsza niż usenet;)

> stresci co wyczytal w google i co jest
> lepsze od czegos to ok i mozna pogadac,
> ale pod linki nie zagladam z braku czasu)

Ale wtedy Ty nie jesteś żadnym partnerem do dyskusji.
Nie wspominając o tym, żę marnujesz tak więcej czasu;]

pzdr, EOT
bartekltg

do góry

W dniu 2013-01-15 19:19, bartekltg pisze:

>> co do mnie (grfr) to przygodnie sie
>> zinteresowalem i nie mam czasu czytac
>> wiki czy praktycznie czegokolwiek
>> innego niz same posty ;\ (tak ze jak ktos
>
> Przeczytałbyś w 20 minut i już byś wszytko wiedział,
> wikipedia jest w przypadku prostych rzeczy naprawdę
> wydajniejsza niż usenet;)
>
>> stresci co wyczytal w google i co jest
>> lepsze od czegos to ok i mozna pogadac,
>> ale pod linki nie zagladam z braku czasu)
>
> Ale wtedy Ty nie jesteś żadnym partnerem do dyskusji.
> Nie wspominając o tym, żę marnujesz tak więcej czasu;]

Gdybyś śledził grupę od dawna wiedziałbyś, że fir _nigdy_ nie czyta
podanych linków. Od zawsze pisze "bo nie ma czasu", albo "że i tak nic
wartościowego w linkach nie ma więc nie warto czytać" itp. bzdury. Same
dresy w tych linkach piszą.
To między innymi dlatego wciąż w kółko próbuje wynajdywać koła i
masz mu streścić, bo inaczej nie jesteś partnerem do dyskusji.
Inne jego zwyczaje pominę z litości.

Pozdrawiam
Piotr

do góry