#v-measure

[mik-es-robgak]

Amikor nem figyelsz és a V-Measure fát rosszul frissíted, töröltem az előzőleg felvitt de nem helyes dokumentumot a fából, majd nem frissítettem az újjonan létrehozott clusterrel a fát így telejsen szét esett az egész mérés :)

[mik-es-robgak]

V-Measure test

A CPN-emben használt V-Measure implementációmat teszteltem. V-Measure áll a Homogeneity-ből, ami a cluster egyneműségét figyeli, vagyis, ha, egy clusterbe, csak egy féle kategóriájú inputok tartoznak akkor 1 lesz, áll a Completeness-ből ami egy kategória teljességét figyeli, vagyis, ha, egy kategóriához tartozó inputok csak egy clusterben szerepelnek, akkor az értéke 1 lesz.

Ezzel csak "büntetni" lehet a clusterek elmozdulási mértékét, azaz, ha felbomlik a Homogeneity vagy a Completeness akkor az már csak rontani tud a cluster újra pozícionálásában. De ezzel azt érjük el hogy tovább nem ront a helyzetén a cluster, hanem teret enged más jobb helyzetben lévő clustereknek.

Képekhez az adatok: http://pastebin.com/4Y2iebg4

Magyarázat: Legjobb oldali input az első input, legfelső pedig az utolsó, óramutatóval megegyezően dolgozódnak fel az inputok.

1.kép az 1.Case-hez tartozik, itt a V-Measure végig 1, tehát normálisan működik a LearningRate az újrapozícionáláskor.

2.kép a 2.Case-hez tartozik, amikor az utolsó inputom más kategóriájú, igy a Homogeneity egyből 0 lesz (lehet hibás, az a biztos hogy nem 1 lesz ilyenkor) ezért elsem mozdul a hibás input felé a cluster, hogy el ne rontsa az értékeit. Itt azért 0 egyből mert már eddig elég sok egynemű inputok tartoznak hozzá, és emiatt uralkodóbbá válnak és egyből elnyomják az új telejsne rossz inputot.

3.kép a 3.Case-hez tartozik, itt az utolsó 2 inputom más kategóriájú mint az első kettő, itt is ugyan az látható mint az előbbi esetben, hogy amint más kategóriájú input érkezik csökken a Homogeneity, de itt nem lesz egyből 0, mert eddig csak 2 példa volt előtte. Itt már a 2. és 3. iteráció, nyerés közben sokkal kisebb az elmozdulás, mert a V-Measure hatott a clusterre, hogy ne legyen annyira inhomogén.

4. és az 5.kép a 4.Case-hez tartozik, amikor is a 4.képen az inputok kategóriája komplementerei az 5.képen lévő inputokénak. Jól mutatja, hogy ha az első input kateógiája az egyedüli a többi inputhoz képest, akkor próbál a cluster az 1.input közelében maradni. Azt is jól mutatja, hogy mennyire fontos az inputok sorrendisége a feldolgozás szempontjából.

6.kép az 5.Case-hez tartozik, amikor már 3 kategória játszik, és ezek pont az inputok "közepén" helyezkednek el sorrendiségben. Ilyenkor sokkal jobban megtorpan a cluster elmozdulása, a Homogeneity sokkal roszabb lesz mint az előző esetekben. Nem lesz ittsem egyből 0, de kevesebb lesz a 3. nyeréskor mint az előző esetben. Az is jól látszik, hogy már el lett rontva a cluster, mert a 4. helyes kategóriájú inputot megsme próbálja megközelíteni, persze itt kiegyenlített a küzdelem mert eddig 3 input 3 különböző kategória. Feltételezem, hogy még az elején 3 azonos kategóriájú input lenne mint az utolsó akkor már mozdulna felé a cluster.

7.kép a 6.Case-hez tartozik, amikor már két cluster játszik, de mivel minden input azonos kategóriájú, ezért a V-Measure 1, azaz nem szól bele a cluster elmozdulásba ezért minden inputot egy cluster tud reprezentálni.

8.kép is a 6.Case-hez tartozik. Itt viszont már a 2. input más kategóriához tartozik, ezért a 3. inputhoz már nem mozdul akkorát a V-Measure miatt, így a másik cluster lezs hozzá közelebb, így ő nyer, pedig az első és a harmadik input azonos kategóriájú. Ebből az következik, hogy a V-Measure miatt elrontott cluster hagyja, hogy másik cluster törjön előre amely nagyvalószínűséggel jobb V-Measure el rendelkezik, vagy egyszerűen közelebb van és jobban reprezentálja az új inputot. Az az egy elrontott cluster ne birtokoljon több, sok inputot, mert már úgy is el van rontva és gondolom ha továbbra is begyűjtené az inputokat akkor a Homogeneity és a Completeness felborulása miatt a vegyes inputokat sem tudná megfelelően reprezentálni, egyszerre sok kategóriát kellene kezelnie, az az a grossberg mátrixban sosem a megfelelő kategória nyerne, egymás ellen viaskodnának az updateGrossberg időszakban.

Summary: Azaz, ha minél több féle kategóriájú inputot tartalmaz egy cluster annál nagyobb versengés alakul ki majd a Grossberg, outstar rétegben, ami pedig sosem fog feloldódni, ha csak kinem találnak valami módszert erre, de nem valószínű, mert a cluster alapvetően rossz inputokat reprezentál. Ha egy kategóriához tartozó inputok több clusterbe tartoznak, de az a cluster homogén az nem tűnik bajnak, inkább csak szemcsésebbé teszi a felbontást az asszociációknál, vagyis valószínű nagyon bonyolult alakzatban vannak szétszorva az azonos kategóriájú inputok, több mag létezik.

PS.: Még megkell valósítani azt az esetet amikor h=1, c<1, ez az az eset amit előbb leírtam.

UPDATE: 9.kép, 7.Case http://pastebin.com/CGvdMV97

Nagy valószínűséggel rosszul működik a V-Measure-öm abban az esetben amikor sok azonos kategóriájú input után egy más kategóriájú jön, mert a Homogeneity egyből 0-zódik és amikor sok azonos clusterhez és azonos kategóriához tartozó input után egy másik cluster nyeri meg az azonos kategóriájú inputot, ekkor a Completeness egyből 0 lesz, ami biztos nem jó. :S

Tehát a szélsőséges esetek rosszul működnek, a többi pedig jól :) :S

[mik-es-robgak]

Sajna még mindig szerencsétlenkedem! Kéne egy igazi Debug is már készen is lennék!

[mik-es-robgak]

Kicsit sem járok közel az igazsághoz :)

Még az sem tisztázódott bennem, hogy ezt a V-Measure-t minden inputhoz számolhatom on-the-fly, és így persze időben előre menőleg pontosul majd a V-Measure, vagy kell egy elő iteráció, előfeldolgozás, hogy véglegesen beálljanak a clusterek és utána már tudjam újra tanítani őket. De az első a nagyobb valószínűségű dolog.