Użytkownik "Segmentation Fault" <c...@o...eu> napisał w
wiadomości news:4c595e1a$0$2604$65785112@news.neostrada.pl...
> A jak liczysz i porównujesz histogramy ?
> Ja bym policzył "ile każdego znaczka", potem bym znormalizował
> ( podzielił wystąpienia każdego znaczka przez ilość wszystkich znaczków
> w tekście ). Przy 12.000 znaków "najmniejsza" liczba to będzie 0.000083,
> więc jeszcze mieści się we float, na pewno w double.

Najpierw przechodzę plik i zliczam wystąpienie znaku w tablicy 256 wordów.
Więcej niż połowa pól tej tablicy jest zwykle zerowa. Mam
prawdopodobieństwa, czyli ilość wystąpień znaków podzieloną przez np.12000.
Prawdopodobieństwo to np. 1/100. Teraz gdy mnożę 1/100*1/100*..1/100 np.
tysiąc razy otrzymuję liczbę mniejsza niż najmniejsza możliwa rzeczywista,
dlatego potrzebna jest normalizacja. Normalizuję w ten sposób że ustawiam
cechę na 1023 co oznacza że liczba staje się z przedziału (1;2) oraz sumuję,
ile do kolejnych cech dodałem.
Otrzymuję bardzo zdecydowane rozkłady prawdopodobieństw - jedynka dla klasy
z którą się zgadza i liczby bardzo bliskie zera dla pozostałych klas. Kłopot
jest z Unicodem który ma ten sam histogram niezależnie czy kolejność bajtów
w znaku jest młodszy-starszy czy odwrotnie. Nie opłaca się robić tablicy par
znaków zamiast znaków bo oznaczałoby to 256 krotne powiększenie tablicy
(albo trochę mniej po odrzuceniu pustych i zorganizowaniu tego jako nie
tablicy). Zamierzam zrobić dwie tablice po 256 znaków specjalnie dla
Unicode - częstości parzystych i nieparzystych bajtów, z których to tablic
program korzystałby gdyby zaklasyfikował już tekst jako Unicode.

> Potem te znormalizowane histogramy porównywał bym np. licząc korelację
> ( albo poeksperymentował bym z innymi metodami; wzorki tu:
> http://opencv.willowgarage.com/documentation/histogr
ams.html#comparehist

Ciekawe, można by jeszcze porównywac dwa histogramy.

Pozdrawiam

do góry

On 08/04/2010 09:19 PM, Borneq wrote:
> Użytkownik "Segmentation Fault" <c...@o...eu> napisał w
> wiadomości news:4c595e1a$0$2604$65785112@news.neostrada.pl...
>> A jak liczysz i porównujesz histogramy ?
>> Ja bym policzył "ile każdego znaczka", potem bym znormalizował
>> ( podzielił wystąpienia każdego znaczka przez ilość wszystkich znaczków
>> w tekście ). Przy 12.000 znaków "najmniejsza" liczba to będzie 0.000083,
>> więc jeszcze mieści się we float, na pewno w double.
>
> Najpierw przechodzę plik i zliczam wystąpienie znaku w tablicy 256
> wordów. Więcej niż połowa pól tej tablicy jest zwykle zerowa. Mam
> prawdopodobieństwa, czyli ilość wystąpień znaków podzieloną przez np.12000.
> Prawdopodobieństwo to np. 1/100. Teraz gdy mnożę 1/100*1/100*..1/100 np.
> tysiąc razy otrzymuję liczbę mniejsza niż najmniejsza możliwa
> rzeczywista, dlatego potrzebna jest normalizacja.

Ale dlaczego mnożysz tyle razy ?
Czy nie wystarczy policzyć histogram, znormalizować i porównać go ze
wzorcowymi, znormalizowanymi histogramami dla każdego z kodowań?
I wybrać "najbardziej podobne" kodowanie ?

( Znormalizować znaczy żeby sumował się do 1, jak rozkład
prawdopodobieństwa )

Wzorcowy histogram może być z dużego tekstu; jeśli histogramy z różnych
długich tekstów w tym samym języku i kodowaniu będą się dużo różnić, to
i tak pomysł z histogramem nie zadziała ).


Normalizuję w ten
> sposób że ustawiam cechę na 1023 co oznacza że liczba staje się z
> przedziału (1;2) oraz sumuję, ile do kolejnych cech dodałem.
> Otrzymuję bardzo zdecydowane rozkłady prawdopodobieństw - jedynka dla
> klasy z którą się zgadza i liczby bardzo bliskie zera dla pozostałych
> klas. Kłopot jest z Unicodem który ma ten sam histogram niezależnie czy
> kolejność bajtów w znaku jest młodszy-starszy czy odwrotnie. Nie opłaca
> się robić tablicy par znaków zamiast znaków bo oznaczałoby to 256 krotne
> powiększenie tablicy (albo trochę mniej po odrzuceniu pustych i
> zorganizowaniu tego jako nie tablicy). Zamierzam zrobić dwie tablice po
> 256 znaków specjalnie dla Unicode - częstości parzystych i nieparzystych
> bajtów, z których to tablic program korzystałby gdyby zaklasyfikował już
> tekst jako Unicode.
>
>> Potem te znormalizowane histogramy porównywał bym np. licząc korelację
>> ( albo poeksperymentował bym z innymi metodami; wzorki tu:
>> http://opencv.willowgarage.com/documentation/histogr
ams.html#comparehist
>
> Ciekawe, można by jeszcze porównywac dwa histogramy.
>
> Pozdrawiam

do góry

Użytkownik "Segmentation Fault" <c...@o...eu> napisał w
wiadomości news:4c59ca48$0$19184$65785112@news.neostrada.pl...
> Ale dlaczego mnożysz tyle razy ?
> Czy nie wystarczy policzyć histogram, znormalizować i porównać go ze
> wzorcowymi, znormalizowanymi histogramami dla każdego z kodowań?
> I wybrać "najbardziej podobne" kodowanie ?

Patrzyłem na różne funkcje dotyczące histogramów na przykładzie
rozpoznawania spamu. Występują małe różnice w d(H1,H2) i nie zachowują się
jak trzeba (różnica między spamem a niespamem ma być większa niż między nimi
a testowym). Korelacja raczej sprawdza czy wykres punktów (Xi,Yi) leży
bliżej prostej y=x czy y=-x, u mnie to nie występuje. Za to Bayes nadaje się
do tego, mamy wielokrotne mnożenie prawdopodobieństw i kolosalne różnice
między najlepszym histogramem a innymi.
Nie stosuję wzoru
http://en.wikipedia.org/wiki/Bayesian_spam_filtering
#Combining_individual_probabilities
nie wiem czy jest dobry i skąd się wziął a także jest niepotrzebny skoro
możemy po prostu mnożyć prawdopodobieństwa z histogramu przez siebie.

do góry