W jaki sposób można rozpoznawać stronę kodową np. Latin2, Windows1250,UTF8
na podstawie tekstu, czy do tego mogą przydać się algorytmy bayesowskie?

do góry

Użytkownik "Borneq" <b...@a...hidden.pl> napisał w wiadomości
news:i317b8$4q1$1@news.onet.pl...
> W jaki sposób można rozpoznawać stronę kodową np. Latin2,
> Windows1250,UTF8 na podstawie tekstu, czy do tego mogą przydać się
> algorytmy bayesowskie?

Jeśli chodzi o Bayesa to najwięcej można znaleźć na temat klasyfikowania
spamu. A jak w przypadku znaków? są podobieństwa i różnice, np. dla hipotezy
UTF8 jeden znak ma kilka bajtów a te same bajty w innej hipotezie oznaczają
kilka kolejnych znaków.

do góry

On 07/31/2010 03:10 PM, Borneq wrote:
> W jaki sposób można rozpoznawać stronę kodową np. Latin2,
> Windows1250,UTF8 na podstawie tekstu, czy do tego mogą przydać się
> algorytmy bayesowskie?

Ja bym zaczął od histogramów; kolejność znaków nie jest ważna przy
rozpoznawaniu kodowania.

do góry

W dniu 2010-08-01 00:26, Segmentation Fault pisze:
> On 07/31/2010 03:10 PM, Borneq wrote:
>> W jaki sposób można rozpoznawać stronę kodową np. Latin2,
>> Windows1250,UTF8 na podstawie tekstu, czy do tego mogą przydać się
>> algorytmy bayesowskie?
>
> Ja bym zaczął od histogramów; kolejność znaków nie jest ważna przy
> rozpoznawaniu kodowania.

W przypadku języka polskiego obstawiam, że może pomóc. Być może np.
'ó' będzie często poprzedzało 'w'.

--
Paweł Kierski
n...@p...net

do góry

Użytkownik "Paweł Kierski" <n...@p...net> napisał w wiadomości
news:i3348k$779$1@news.onet.pl...
> W przypadku języka polskiego obstawiam, że może pomóc. Być może np.
> 'ó' będzie często poprzedzało 'w'.

Dla polskich kodowań ISO 8859-2 Latin-2 czy Windows-1250 mamy tylko 9 dużych
i 9 małych znaków narodowych a reszta to Ascii i wystarczy tylko zbadać
częstotliwość tych znaków, bo gdzie dla jednego kodowania będą te znaki to
dla drugiego nie będą. Można by badać częstotliwość tylko znaków o kodzie
>127.
Dla cyrylicy jest inaczej, dla różnych kodowań są to znaki o kodach >127 i
jeden znak w jednym kodowaniu odpowiada legalnemu znakowi w innym kodowaniu.
Czyli jeden znak nie wystarczy, trzeba by badać częstotliwość par znaków.
Dodatkowa trudność dochodzi gdy mamy zbadać czy nie mamy do czynienia z
UTF-8. Tu mamy pary znaków, należy badać pary i uwaga - para zawsze musi
zaczynać się od pierwszego bajtu utf-8. Pomocne będzie wyrzucenie znaków o
kodach <128. Jednak tu problem; gdy mamy polskie ośmiobitowe kodowanie to
gdy badamy częstotliwość to nie interesują nas pary "ąó" gdy te litery są
oddzielone znakami Ascii ale raczej pary "ów" czyli nie wyrzucamy pary, gdy
którykolwiek ma kod>128 (a raczej pierwszy, bo gdy drugi>128 to może być
pierwszym znakiem utf-8)

do góry

Użytkownik "Borneq" <b...@a...hidden.pl> napisał w wiadomości
news:i318sm$94e$1@news.onet.pl...
> Jeśli chodzi o Bayesa to najwięcej można znaleźć na temat klasyfikowania
> spamu

Szukam przykładu gdzie sposób bayesowski był by dobrze wytłumaczony na
liczbach. W
http://inf.ug.edu.pl/~stefan/Dydaktyka/SztIntel/Slaj
dy/05-26a.pdf jest
przykład na pomarańczach który rozumiem chociaż mam uwagę że
prawdopodobieństwo niebieskiego naczynia wynosi 1/3 bo jest tam dwa razy
mniej kulek niż w czerwonym a według mnie najpierw wybieramy naczynia z
prawdopodobieństwem 1/2 a dopiero potem jabłko lub pomarańczę.
Na stronie 8 tego pdf mamy wyliczanie prawdopodobieństwa tego że zbiór słów
odpowiada spamowi. Czy tutaj zaklasyfikowanie jako spam jest bardziej
prawdopodobne bo zbiór treningowy spamów jest 3 razy większy niż nie spamów?
Tutaj nie rozumiem skąd się wzięły liczby według których odbywa się
liczenie.
Licznik jeszcze można wytłumaczyć że w P(rynek|S) mamy 1+1 bo słowo "rynek"
występuje w spamie raz i w treningowym raz, P(szybko|S) mamy 2+1 bo słowo
"szybko" występuje 2 razy w spamie a raz w badanym.
Ale co oznaczają liczby w mianowniku? 13 to ilość wszystkich słów a inne
liczby można by tylko dopasować do przykładu (a zbieżność może być
przypadkowa bo mamy tylko jeden przykład). 8 to ilość słów w spamie, 5 suma
w niespamie i w badanym, 2 w badanym. Jednak coś się tu nie zgadza gdy w
mianowniku mamy sumę 2+5, więc 5 to nie suma, poza tym zaznaczona że dotyczy
badanego a dwójka nie spamu. Więc coś się tu nie zgadza.
W http://www.paulgraham.com/naivebayes.html mamy inny wzór na wyliczanie
prawdopodobieństwa.

do góry

Użytkownik "Borneq" <b...@a...hidden.pl> napisał w wiadomości
news:i33d3s$r0i$1@news.onet.pl...
> że dotyczy badanego a dwójka nie spamu. Więc coś się tu nie zgadza.

Ma to pewien związek z wygładzaniem Laplace'a opisanym w dalszej części
wykładu. Przyjrzę się, wygląda na to że się zgadza.

do góry

On 08/01/2010 10:56 AM, Borneq wrote:
> Użytkownik "Paweł Kierski" <n...@p...net> napisał w wiadomości
> news:i3348k$779$1@news.onet.pl...
>> W przypadku języka polskiego obstawiam, że może pomóc. Być może np.
>> 'ó' będzie często poprzedzało 'w'.
>
> Dla polskich kodowań ISO 8859-2 Latin-2 czy Windows-1250 mamy tylko 9
> dużych i 9 małych znaków narodowych a reszta to Ascii i wystarczy tylko
> zbadać częstotliwość tych znaków, bo gdzie dla jednego kodowania będą te
> znaki to dla drugiego nie będą. Można by badać częstotliwość tylko
> znaków o kodzie >127.
> Dla cyrylicy jest inaczej, dla różnych kodowań są to znaki o kodach >127
> i jeden znak w jednym kodowaniu odpowiada legalnemu znakowi w innym
> kodowaniu. Czyli jeden znak nie wystarczy, trzeba by badać częstotliwość
> par znaków. Dodatkowa trudność dochodzi gdy mamy zbadać czy nie mamy do
> czynienia z UTF-8. Tu mamy pary znaków, należy badać pary i uwaga - para
> zawsze musi zaczynać się od pierwszego bajtu utf-8. Pomocne będzie
> wyrzucenie znaków o kodach <128. Jednak tu problem; gdy mamy polskie
> ośmiobitowe kodowanie to gdy badamy częstotliwość to nie interesują nas
> pary "ąó" gdy te litery są oddzielone znakami Ascii ale raczej pary "ów"
> czyli nie wyrzucamy pary, gdy którykolwiek ma kod>128 (a raczej
> pierwszy, bo gdy drugi>128 to może być pierwszym znakiem utf-8)

No dobra, ale to nie przeszkadza w liczeniu histogramów. Histogram musi
być po prostu lepiej budowany, nie bajt po bajcie.
Nie musi też przeszkadzać, że niektóre znaki w różnych kodowaniach
znaczą coś innego. Prawdopodobnie występują z różną częstotliwością
i to wyjdzie przy porównywaniu histogramów.

Na Twoim miejscu zaczął bym od sprawdzenia jak zadziała histogram na
Twoich danych, przed zaprzęganiem bayesa. I tak Ci się przyda porównanie
z "prostszą" metodą, jak zrobisz tą bardziej skomplikowaną.

do góry

Użytkownik "Segmentation Fault" <c...@o...eu> napisał w
wiadomości news:4c57d3da$0$2605$65785112@news.neostrada.pl...
> Na Twoim miejscu zaczął bym od sprawdzenia jak zadziała histogram na
> Twoich danych, przed zaprzęganiem bayesa. I tak Ci się przyda porównanie
> z "prostszą" metodą, jak zrobisz tą bardziej skomplikowaną.

Na razie mam zbiór treningowy niezbyt duży 12 kB i taki sam (czyli duży)
zbiór testowy. Przy takiej ilości testowej prawdopodobieństwo bardzo szybko
przekracza minimalny zakres liczb (staje się mniejsze nawet niż 1e-32000)
dlatego liczby muszą być normalizowane. Dla porównania między Windows1250 a
Latin2 wystarcza histogram jednobajtowy i niedużo polskich liter w testowym
tekście aby doskonale rozróżnił. Należy zauważyć że te dwa standardy są
bardzo podobne, 12 na 18 znaków jest identycznych, ale wystarczył jeden znak
ś aby rozkład prawdopodobieństwa wyniósł 98.15% do 1.85%. Gdyby nie
wygładzanie (dodawanie jedynki do licznika i liczby znaków do mianownika w
celu eliminacji prawdopodobieństwa zerowego) byłoby to 100% do 0% - nic
dziwnego skoro litera występuje w jednym zbiorze kontrolnym a w drugim nie.
Zobaczymy jak to będzie dla Utf-8 i Utf-16. Dla tego ostatniego częstość
występowania jednego bitu nie wystarczy, bo może być w postaci big-endian i
little-endian ale ogólnie 1 bajtowe porównanie na tym przykładzie dobrze
sobie radzi.

do góry

On 08/04/2010 01:45 AM, Borneq wrote:
> Użytkownik "Segmentation Fault" <c...@o...eu> napisał w
> wiadomości news:4c57d3da$0$2605$65785112@news.neostrada.pl...
>> Na Twoim miejscu zaczął bym od sprawdzenia jak zadziała histogram na
>> Twoich danych, przed zaprzęganiem bayesa. I tak Ci się przyda porównanie
>> z "prostszą" metodą, jak zrobisz tą bardziej skomplikowaną.
>
> Na razie mam zbiór treningowy niezbyt duży 12 kB i taki sam (czyli duży)
> zbiór testowy. Przy takiej ilości testowej prawdopodobieństwo bardzo
> szybko przekracza minimalny zakres liczb (staje się mniejsze nawet niż
> 1e-32000) dlatego liczby muszą być normalizowane.

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.

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
)

do góry