Ekezetesito program :)

Ha mar ennyire (kovaszos) uborkaszezon van, elovettem egy regi otletem: irni egy olyan programot, ami ekezet nelkuli szoveget ekezetesit. Tuti irt mar valaki ilyet, hallottam mar olyanrol aki ismer olyat akinek az ukannya latott is talan valahol az erdoben, de en nem talaltam.

Az eredeti otletem az volt, hogy neuralis haloval, szovegkornyezet alapjan word2vec-et felhasznalva talalna ki, hogy a tobbfele irasmod kozul vajon ott melyikre lehet szukseg. Ehhez eloszor is fogtam par ezer ujsagcikket, es osszedobtam egy python scriptet (gen_map.py) ami szavankent megnezi a gyakorisagot es a vegen kilistazza melyikek azok a szavak, ahol tobbfele ekezetes alak tartozik ugyanahhoz az ekezet nelkulihez. A meglepetes akkor jott, mikor lefuttattam (par bugfix utan:)), es kiderult, hogy a szavak kb 90%-anak csak egyfele alakja van, tehat 1:1 lekepzesrol van szo. A maradekban viszont nagyon sok olyan van, ahol nem a szoveg temaja (amire a word2vec jo lenne) miatt kell kulonbozo alakot hasznalni, hanem a nyelvtan, pl. ragozas miatt. Igy elso korben el is vetettem a neuralis halot, nezzuk meg csak siman statisztikailag hogy mukodik!

Osszeszedtem a word2vec tanitashoz gyujtott anyagokbol 4GB-nyi tiszta szep magyar szoveget (wikipedia mellett ujsagcikkek, konyvek szovege), osszesen kb felmillio szo:

   5632380  518183909 4166064575 input.txt

Egy ora alatt lefutott ezen is, 8822173 kulonbozo szo, de ebbol csak 511820 szo fordult elo 25-szor legalabb, igy a tobbivel nem is foglalkozunk. Ezek kozul 24377 eseten van 1-nel tobb alak ugyanahhoz az ekezetlenitett verziohoz, osszesen 337570 eseten ter el az ekezetes valtozat, tehat itt is tobb, mint 90%-a 1:1 csere lesz!

Az eredmenyt kidumpoltam pickle-vel (wordmap.pck) es irtam egy masik scriptet (use_map.py) a teszteleshez, ez stdin-en kapott tx-ben kicsereli az ekezetes megfelelokre a szavakat (ahol tobb lehetoseg van, ott a 2 leggyakoribbat irja bele |-al elvalasztva), es kiirja az stdout-ra. Meg nem tokeletes, kisbetu-nagybetu kezeles es nem space-el elvalasztott szaval eseten bugzik, de ez csak teszt...

Kommentbe felrakom ezen iras automatikusan ekezetesitett verziojat erdekesseg keppen, ha pedig kiprobalnad, itten vala:

http://thot.banki.hu/ekezet/

Hasznalatahoz eleg a use_map.py es wordmap.pck file. a py script stdin-rol stdout-ra (unix pipe/filter logika) dolgozik!

TODO: bugok javitasa, es lefuttatni sokkal nagyobb inputon is.

A'rpi

( arpi_esp v | 2022. 07. 02., szo – 19:24 )

es az igert output, ahogy a gepbol kijott, modositas nelkul:

 

 

Ha már ennyire (kovaszos)uborkaszezon van, elővettem egy régi otletem: írni egy olyan programot, ami ékezet nélküli szöveget|szövegét ekezetesit. Tuti írt már valaki ilyet, hallottam már olyanról aki ismer olyat akinek az ukannya látott is talán valahol az erdőben, de én nem találtam.

Az eredeti ötletem az volt, hogy neurális hálóval, szövegkörnyezet alapján word2vec-et felhasználva találna|találná ki, hogy a többféle|többfelé írásmód közül vajon ott melyikre lehet szükség. Ehhez először is fogtam pár ezer újságcikket, és osszedobtam egy python scriptet (gen_map.py) ami szavanként megnézi a gyakoriságot és a végén kilistázza melyikek azok a szavak, ahol többféle|többfelé ékezetes alak tartozik ugyanahhoz az ékezet nelkulihez. A meglepetés akkor jött, mikor lefuttattam (pár bugfix utan:)), és kiderült, hogy a szavak kb 90%-ának csak egyféle alakja van, tehát 1:1 lekepzesrol van szó. A maradékban viszont nagyon sok olyan van, ahol nem a szöveg témája (amire a word2vec jó lenne) miatt kell különböző alakot használni, hanem a nyelvtan, pl. ragozás|rágózás miatt. így első körben el is vetettem|vétettem a neurális hálót, nézzük meg|még csak simán statisztikailag hogy működik!

összeszedtem a word2vec tanításhoz gyűjtött anyagokból 4GB-nyi tiszta szép magyar szöveget|szövegét (wikipedia mellett újságcikkek, könyvek szovege), kb összesen félmillió szó:

5632380 518183909 4166064575 input.txt

Egy óra alatt lefutott ezen is, 8822173 különböző szó, de ebből csak 511820 szó fordult elő|élő 25-ször legalább, így a többivel nem is foglalkozunk. Ezek közül 24377 esetén van 1-nél több alak ugyanahhoz az ekezetlenitett verzióhoz, összesen 337570 esetén tér el az ékezetes változat, tehát itt is több, mint 90%-a 1:1 csere lesz!

Az eredményt kidumpoltam pickle-vel (wordmap.pck) és írtam egy másik scriptet (use_map.py) a teszteléshez, ez stdin-en kapott tx-ben kicseréli az ékezetes megfelelokre a szavakat (ahol több lehetőség van, ott a 2 leggyakoribbat írja bele |-al elvalasztva), és kiírja az stdout-ra. meg|még nem tökéletes, kisbetu-nagybetu kezelés és nem space-el elválasztott szaval esetén bugzik, de ez csak teszt...

Kommentbe felrakom ezen írás automatikusan ekezetesitett verzióját, ha pedig kiprobalnad, itten vala:

http://thot.banki.hu/ekezet/

A kiprobalashoz elég a use_map.py és wordmap.pck file. a py script stdin-rol stdout-ra (unix pipe/filter logika) dolgozik!

TODO: bugok javítása, és lefuttatni sokkal nagyobb inputon is.

A'rpi

vajon az "otletem"-nek mi a tobbi alakja? 5letem? ottlétem? :)

Az "osszedobtam" -ot se tudom hova tenni, szerintem annak is csak egy alakja van.

Amugy hasznalhatonak tunik.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

nem az a baj veluk, hogy tobb alakja van (akkor a leggyakoribb 2-re cserelne), hanem hianyzik a szokincsebol... keves volt az input vagy tul eros a >25 elofordulasos eloszuro. azert is van a TODO-ba hogy tobb inputtal kene tanittatni...

meg ugyanaz a problema mint a spamszuronel volt az elerheto word2vec modellekkel, tul steril szoveggel van tanitva, a koznyelvet/szlenget/szakszoveget nem ismeri...

itt van amugy a gyakorisag alapjan rendezett lista a szavak alakjairol amit ismer:

http://thot.banki.hu/ekezet/words.log

 

9751458 es és
3268157 meg [(1915242, 'meg'), (1352853, 'még')]
1656212 mar már
1015916 tobb több
964677 ket két
924113 igy így
912720 utan után
866027 elso első
791048 fel [(648368, 'fel'), (142662, 'fél')]
766416 uj új
723259 ugy úgy
722331 kozott között
515983 millio millió

...

A helytelenül írt szavak pl. ukannya eleve zsákutca, mert ha leírod helytelenül és még fel is ékezetesíti, az már elég vicces tud lenni. Ha pl. a megragom helyett sikerül leírni a megrakom-ot, akkor alapból is poénos ha úgy marad, de ha még megrákom is lesz belőle és több ilyen van egymás után, akkor azért el tudja veszíteni az ember a fonalat.

Amúgy faja, gondolom még bőven lehet tekergetni a potmétereket, hogy jobb legyen :D

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

v2, 10GB szovegbol, >5 elofordulassal tanitva:

hibak:

nem ismeri:  lekepzesrol, ekezetesit, ekezetesitett, ekezetlenitett

ekezet nelkulit is felajanl:  ékezet|ekezet, wikipedia|wikipédia, kiírja|kiirja

v2 output:

 

Ha már ennyire (kovászos) uborkaszezon van, elővettem egy régi ötletem: írni egy olyan programot, ami ékezet|ekezet nélküli szöveget|szövegét ekezetesit. Tuti írt már valaki ilyet, hallottam már olyanról aki ismer olyat akinek az ukannya látott is talán valahol az erdőben, de én nem találtam.

Az eredeti ötletem az volt, hogy neurális hálóval, szövegkörnyezet alapján word2vec-et felhasználva találna|találná ki, hogy a többféle|többfelé írásmód közül vajon ott melyikre lehet szükség. Ehhez először is fogtam pár ezer újságcikket, és összedobtam egy python scriptet (gen_map.py) ami szavanként megnézi a gyakoriságot és a végén kilistázza melyikek azok a szavak, ahol többféle|többfelé ékezetes alak tartozik ugyanahhoz az ékezet|ekezet nélkülihez. A meglepetés akkor jött, mikor lefuttattam (pár bugfix után:)), és kiderült, hogy a szavak kb 90%-anak csak egyféle|egyfelé alakja van, tehát 1:1 lekepzesrol van szó. A maradékban viszont nagyon sok olyan van, ahol nem a szöveg témája (amire a word2vec jó lenne) miatt kell különböző alakot használni, hanem a nyelvtan, pl. ragozás|rágózás miatt. így első körben el is vetettem|vétettem a neurális hálót, nézzük meg|még csak simán statisztikailag hogy működik!

összeszedtem a word2vec tanításhoz gyűjtött|gyújtott anyagokból 4GB-nyi tiszta szép magyar szöveget|szövegét (wikipedia|wikipédia mellett újságcikkek, könyvek szövege), összesen kb félmillió szó:

5632380 518183909 4166064575 input.txt

Egy óra alatt lefutott ezen is, 8822173 különböző szó, de ebből csak 511820 szó fordult elő|élő 25-szor legalább, így a többivel nem is foglalkozunk. Ezek közül 24377 esetén van 1-nel több alak ugyanahhoz az ekezetlenitett verzióhoz, összesen 337570 esetén tér el az ékezetes változat, tehát itt is több, mint 90%-a 1:1 csere lesz!

Az eredményt kidumpoltam pickle-vel (wordmap.pck) és írtam egy másik scriptet (use_map.py) a teszteléshez, ez stdin-en kapott tx-ben kicseréli az ékezetes megfelelőkre a szavakat (ahol több lehetőség van, ott a 2 leggyakoribbat írja bele |-al elválasztva), és kiírja|kiirja az stdout-ra. meg|még nem tökéletes, kisbetu-nagybetu kezelés és nem space-el elválasztott szaval esetén bugzik, de ez csak teszt...

Kommentbe felrakom ezen írás automatikusan ekezetesitett verzióját érdekesség képpen, ha pedig kipróbálnád, itten vala:

http://thot.banki.hu/ekezet/

használatához elég a use_map.py és wordmap.pck file. a py script stdin-rol stdout-ra (unix pipe/filter logika) dolgozik!

TODO: bugok javítása, és lefuttatni sokkal nagyobb inputon is.

A'rpi

v4:   gyakori szo-parok alkalmazasaval, valamint a tanitashoz hasznalt inputbol kiszurtem a nem ekezetes szovegeket.

mar egesz jo, alig kell javitani rajta:     (itt a + jel azt jeloli a szo elejen, hogy a szo-parok alapjan dobta ki az alternativat)

 

Ha már ennyire (kovászos) uborkaszezon van, elővettem egy régi ötletem: írni egy olyan programot, ami ékezet nélküli szöveget|szövegét ekezetesit. Tuti írt már valaki ilyet, hallottam már olyanról aki ismer olyat akinek az ukannya látott is talán valahol az erdőben, de én nem találtam.

Az eredeti ötletem az volt, hogy neurális hálóval, szövegkörnyezet alapján word2vec-et felhasználva találna|találná ki, hogy a +többféle írásmód közül vajon ott melyikre lehet szükség. Ehhez először is fogtam pár ezer újságcikket, és összedobtam egy python scriptet (gen_map.py) ami szavanként megnézi a gyakoriságot és a végén kilistázza melyikek azok a szavak, ahol +többféle ékezetes alak tartozik ugyanahhoz az ékezet nelkulihez. A meglepetés akkor jött, mikor lefuttattam (pár bugfix után:)), és kiderült, hogy a szavak kb 90%-ának csak +egyféle alakja van, tehát 1:1 lekepzesrol van szó. A maradékban viszont nagyon sok olyan van, ahol nem a szöveg témája (amire a word2vec jó lenne) miatt kell különböző alakot használni, hanem a nyelvtan, pl. ragozás|rágózás miatt. így első körben el is +vetettem a neurális hálót, nézzük +meg csak simán statisztikailag hogy működik!

összeszedtem a word2vec tanításhoz gyűjtött|gyújtott anyagokból 4GB-nyi tiszta szép magyar szöveget|szövegét (wikipedia|wikipédia mellett újságcikkek, könyvek szövege), összesen kb félmillió szó:

5632380 518183909 4166064575 input.txt

Egy óra alatt lefutott ezen is, 8822173 különböző szó, de ebből csak 511820 szó fordult +elő 25-ször legalább, így a többivel nem is foglalkozunk. Ezek közül 24377 esetén van 1-nél több alak ugyanahhoz az ekezetlenitett verzióhoz, összesen 337570 esetén tér el az ékezetes változat, tehát itt is több, mint 90%-a 1:1 csere lesz!

Az eredményt kidumpoltam pickle-vel (wordmap.pck) és írtam egy másik scriptet (use_map.py) a teszteléshez, ez stdin-en kapott tx-ben kicseréli az ékezetes megfelelőkre a szavakat (ahol több lehetőség van, ott a 2 leggyakoribbat írja bele |-al elválasztva), és +kiírja az stdout-ra. meg|még nem tökéletes, kisbetű-nagybetű kezelés és nem space-el elválasztott szaval esetén bugzik, de ez csak teszt...

Kommentbe felrakom ezen írás automatikusan ekezetesitett verzióját érdekesség képpen, ha pedig kipróbálnád, itten vala:

http://thot.banki.hu/ekezet/

használatához elég a use_map.py és wordmap.pck file. a py script stdin-ről stdout-ra (unix pipe/filter logika) dolgozik!

todo|tódó: bugok javítása, és lefuttatni sokkal nagyobb inputon is.

A'rpi

( kisbetu v | 2022. 07. 03., v – 07:07 )

lályk

"Normális ember már nem kommentel sehol." (c) Poli

( wlaszi | 2022. 07. 03., v – 08:59 )

Bennem az merült fel kérdésként, hogy milyen nagyobb szövegbázis létezhet ékezet nélkül, amihez az eszköz elkészült? Nekem max IRC log jut eszembe, de kétlem, hogy ez lenne a use case :)

"The only valid measurement of code quality: WTFs/min"

en annyira mexoktam hogy 30 eve ekezet nelkul irok, hogy ha nagyritkan valami hivatalos helyre levelet vagy pl. cikket kell irnom, azt is... ilyenkor jo lehet raereszteni a vegeredmenyre. meg lehetne csinalni belole bongeszo plugint szovegbeviteli mezokhoz, mint egy helyesirasellenorzo :)

( thmir v | 2022. 07. 03., v – 09:37 )

Yvonne: De mire jók a szárnyaló elméleteim, ha csak dísznek kellek az irodátokba, mert kell oda demonstratíve egy nő is?

Forest: Ugyan mar, ne izgulj angyalom :) Te leszel a mi szarnyalo disznonk.

Yvonne: Oké Isti, már egyszer kértem, hogy állítsd vissza az ékezeteidet, de most nyomatékosan megismétlem, mielőtt még vérfürdőt rendeznék.

Forrás: https://qdb.hu/21905?c=1 

( Nickname | 2022. 07. 03., v – 10:57 )

Ha tudnék python-ul, a hunspell-el megsúlyoznám a variációkat mondatonként. :-)

Ugyanitt billentyű-app szótár API kerestetik, amivel még teljesebb lehetne a magyar nyelvkincs statisztikai analízise. (GBoard, Swiftkey és társai) - vagy ez zárt és "adatvagyon" ;-)

/bocs az ekezetekert/

beleraktam a hunspellt is, ahol tobb variacio volt ott megneztem a 2.-at es ha a hunspell szerint nem jo, azt kiszortam...

meg is talalt sok gyakori elirast, helyesirasi hibat:

http://thot.banki.hu/ekezet/v6/hunspell.txt

pl:

Hunspell: vizen 14999 2809
Hunspell: tüzijáték 6822 1155
Hunspell: túrista 17926 1023
Hunspell: tulsó 21334 1435
Hunspell: tipusa 17355 1889
Hunspell: szolíd 6238 1011
Hunspell: szivesen 204973 11920
Hunspell: szives 24528 1965
Hunspell: szivem 43307 3339

( gazsiazasz | 2022. 07. 03., v – 11:12 )

Inkább az ékezet nélküli suttyókat kéne addig ütni, míg meg nem tanulnak rendesen írni!

tudod kisfiu, paran mar akkor is hasznaltunk szamitogepet, amikor meg semmilyen ekezet nem letezett.

unix mernokkent ma is elborzadok a magyar billentyuzeten bevitt unix / linux parancsoktol (es kb barmilyen programozasi nyelven irt kod irasatol).

ovatosabban kritizalj es talan nem tunsz majd olyannyira bunkonak.

Tudod nagyfiú, vannak, akik már akkor is a pelusba szartak, amikor még nem volt angol WC... De egy ideje létezik és az emberek többsége fel tud nőni a feladathoz.

2000-res évek elején még én is menőnek gondoltam IRC-en, hogy nem írunk ékezetet csak azért sem, aztán rá kellett jönnöm, hogy fasság. Mint ahogy szép lassan a kisebbségbe kerültek azok, akik azon pampogtak, hogy jaj, nincs beállítva az UTF-8 a termináljukon (jellemzően, mert lusták voltak) vagy valami feltűnési viszketekségből valami fos klienst használtak.

Tény, hogy troll stílusban írta, de alapvetően igaza van. Ezt a user oldalán kell megoldani bevitelkor, mert utólag megfejteni 100%-osan sose lehet. Ezt el kell fogadni, hogy így megy.

Igazából az sem indok, hogy így kellett, ma már minden rendszer tud ékezeteket, főleg Unicode-ot, és billentyűzetkiosztások között váltani. Pl. továbbra is kódolhatsz amcsi billentyűzeten, de magyar szöveghez átválthatsz magyar kiosztásra.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

> magyar szöveghez átválthatsz magyar kiosztásra

pedig ez baromsag. alapvetoen 2 fele ember letezik:

1. aki vakon gepel, ot nem izgatja mi van a gombokra irva, viszont be van idegzodve hogy melyik betu hol van, es az agyat nagyon nehez atkapcsolgatni hogy hol itt hol ott...

2. aki nezi a billentyuzetet gepeles kozben, oket meg az zavarja ha atkapcsolja akkor nem azt latja...  hacsak nem vesz olyan billentyuzetet amin a gombokban kis kijelzok vannak.

en pl. vakon gepelek 10 ujjal, kicsit gyorsabban mint gepirast tanult anyukam, de keptelen vagyok magyar kiosztassal irni, nem all at az agyam ra hogy pl. az y-z is mashol van... 30 ev alatt nagyon be tudnak egni a neuronok, hidd el.

ami utoljara jo volt kb ilyen vegyes kiosztasra, az dos alatt a multikey nevu csoda. ha jol remlik capslock-al hivta elo az ekezeteket amugy angol kiosztason. tehat vegig angol billentyuzet ment, ha ekezettel kellett a karakter akkor plusz nyomtad a capslockot. talan az altgr-es international-hoz lehetne manapsag hasonlitani.

Nem tudom, én egyik kategóriába sem esek, mert vakon gépelek, de nem okoz gondot fejben váltani amcsi és magyar között. Ez lehet onnan jön, hogy kiskoromban volt lehetőségem gyakorolni Amigán, mert rendesen felbootolva - WB-ből - német, később magyar kiosztás volt, Startup-Sequence nélkül meg amerikai, mert nem tudtam, hogy van olyan, hogy SetMap... :/ Ja, meg a játékok is hol amcsi, hol valami európai kiosztással tolták, melyik hogy.

Szóval szerintem megszokás kérdése. :)
Viszont engem az sem zavar, ha valaki ekezetes text helyett sima ASCII-val tolja. :P

Oldschool Computer - http://oscomp.hu

En tudok irni ekezeteket, csak nem akarok :D Addig kene utnod, amig a szandek fel nem ebred bennem. De amugy UK kiosztasu a billentyuzetem, szoval nincs is rajta ekezet ;)

 

ps.:
- en nem fogok magyar kiosztassal programozni full nemzetkozi cegnel
- en nem fogok par suttyo kedveert valtogatni a kiosztasok kozott

Coding and ADHD should be best friends

( fanta | 2022. 07. 03., v – 12:21 )

Csak nehogy fókabél jöjjön főkábel helyett

$ grep -c egy$ word.list
100

( bithalver | 2022. 07. 03., v – 12:27 )

Szep kezdemenyezes. erdekelne. mire jutsz vele kb 1 honap alatt (zero guny, csak szar diplomacia reszemrol).

( arpi_esp v | 2022. 07. 03., v – 14:10 )

Szerkesztve: 2022. 07. 03., v – 14:38

kibovitettem a "tanitashoz" hasznalt szovegmennyiseget, bele kerult tobbek kozt par oldal forum hozzaszolasai is. az eredmeny hol jobb hol rosszabb lett, nehany szonal nagyon latvanyosan bekerultek a hibas variansok is, 10%-nal nagyobb aranyban, pl:

172253 irtam [(154069, 'írtam'), (18119, 'irtam')]
2820 ekezetes [(2441, 'ékezetes'), (377, 'ekezetes')]

korrekcio gyanant beleraktam, hogy azokat a sorokat (=hozzaszolasokat), ami hiba nelkul abrazolhato us-ascii charseten, skippelje:

HUP (2019-es dump):       lines= 600000   words=1584246  skip=87336
Index forum (kis resze):   lines=1969000   words=4396418  skip=127856

aranyaiban a HUP-on irnak a legtobbet ekezettelenul (14.5%), de meg az index-en is 6.5% az arany.

eredetileg NN-el akartam megoldani, csak meg nem tartok ott, es lehet nem is fogok. eleg nehez erre modelt rahuzni, a word2vec-es elkepzelesem meg ott megbukik, hogy a szovegkornyezet sokszor nem a tema hanem a nyelvtan miatt szamit, es arra az nem jo. a fenti disznos peldara talan jo lenne, de ami a gyakorlatban kijott nekem az altalaban nyelvtantol fugg. persze bele lehetne kavarni hunspellt vagy mas szotovezest/ragozast vagy akar komplett nyelvi modellt is, de annyit nem er.

es ebben eddig az a poen, hogy ugy mukodik egesz jol (alig kell javitani kezzel az outputot), hogy semmit sem tud a nyelvrol, nyelvtanrol, ragozasrol, csak megeszik par giga txt-t es abbol "tanulja" meg.

Egyetértek, hogy elég bonyolult és jó hogy már az alap ilyen jó. Lejjebb amit írtam arra lenne jó, hogy az egész komplexitást ledobnád magadról és azt mondanád, hogy a gépi tanulás oldja meg ha tudja. Kvázi áttolnád a problémát a gép asztalára és nem kellene ilyeneken gondolkodni, mint rag meg spelling.

Ami egyértelmű, ott adott az eredmény, ami meg nem, ott megkérdeznéd az AI-t.

Ugye a pontosságot erősen a változók fogják meghatározni. Vagyis az, hogy mi alapján döntsük el, hogy ha több verziója van az ékezetes szavaknak (amely ugyanahhoz a nem ékezeteshez tartozik).

Mivel valószínűleg túl diverz a cél szó körül álló szavak és környezete, ezért ez nem eléggé jó döntési változó szerintem. Zajt fog adni és a döntés így véletlenszerű lesz. Nem lesz benne korreláció.

A kérdés marad tehát, hogy milyen jó feature vektorokkal lehetne jobban szűkíteni a döntést és minél jobb választ adni minél nagyobb általánosságban, főleg új és ismeretlen szövegeknél is.

Tegyük fel, hogy keressük a "fele" szóhoz az ékezeteket és az alábbi tanító adatunk van szövegkörnyezettel, megmutatva az előtte és utána álló szavakat:

... már ennyi féle ember is ...

... az egész fele kiteszi a ...

... arra felé megy majd ...

Nem egyszerű a feladat. Azt kell megtalálni, hogy milyen változók választása ad erősebb korrelációt arra nézve, hogy melyik ékezetes verzió kell. Szerintem több mindent meg kell próbálni és mérni, hogy melyik add jobb eredményt. De várható, hogy magas zajt fog adni több.

NN nagyon háklis a zajra, használhatatlan lesz megfelelő címkék nélkül, ami nem lesz elérhető. Javaslom hogy véletlen erdőben gondolkodj, ugyanis az a legkevésbé érzékeny a zajos változókra és a működése okán automatikus feature szelekció valósul meg. Tehát ha sok használhatatlan változót beteszel, akkor RF (random forest) kidobálja neked és nem megy félre a tanítás. Illetve túltanításra is kevésbé (nem) érzékeny, szemben NN-el, ami csak kínlódás.

Változók kellenek.

x1, x2, x3, x4 stb -> y

x-ek a változók, y a cél érték. Jelen esetben az y az maga az ékezetes szó. Ehhez kellene létrehozni x változókat. Majd ebből egy tábla és mehet a tanítás.

Az új értéknél pedig csak az x-eket ismerjük, és az y-t keressük. Tehát mik legyenek az x változók?

bedobhatnád a word2vec-et is, nem zavar. Ez mellé rengeteg más dolgot be kellene tenni, ami a keresett szón és az előtte és utána álló szavakon végez számítást. Pár ötlet kapásból:

- szavak közti távolság (https://en.wikipedia.org/wiki/Levenshtein_distance)

- mennyi ékezetes betű van mindegyikben, például ezek összege

- mennyi magánhangzó van bennük

- mennyi mássalhangzó van bennük

- magán vagy mással hangzóval kezdődnek (lehet 0 és 1 érték ez)

meg még ami eszedbe jut. És akkor erre gyönyörűen rá tudod tanítani az RF-et. Python-ban sklearn-t használd, annak az algója tud mutatni egy alap heurisztikus score-t a tanítás pontosságára. Majd ha meg van a tanítás, akkor szavanként végig kérdezgeted az összes szóra. Kb ennyi.

Az sklearn-nek van egy "feature importance" methódusa, amellyel ki tudod iratni, hogy mely változóknak mekkora szerepe volt a tanulásban.

Relatíve nem sok ezt leprogramozni. Sklearn példák nagyon jók. Az egésznek az erejét a megfelelő feature-ök létrehozása fogja adni. Ide kellene sok kreatív ötlet, az RF meg majd kiszórja ami nem használható.

Szerk.: ja, és RF-nél nem kell semmilyen hiperparaméter tuningolás. Mindent csak alapértelmezetten használj. Rengeteget elemeztem, szerintem RF a legkönnyebb, leggyorsabb és legadaptivebb algo amit az emberiség valaha kitermelt. Top 1 nálam. Még az XGBoost működése sem tetszik annyira, mint az eredeti RF, ami bootstrap helyett bagging-et használ, ami jól párhuzamosítható.

( arpi_esp v | 2022. 07. 03., v – 16:31 )

van nehany szo, ahol a 2. alak mar annyira ritka hogy ki is esett a redukcio soran, pedig letezo es mas jelenteso szo:

6352798 mar [(6275619, 'már'), (74776, 'mar')
4305824 vagy [(4283209, 'vagy'), (22542, 'vágy')
4272363 el [(4102940, 'el'), (169235, 'él')
2897175 ugy [(2687239, 'úgy'), (115988, 'ügy')
951327 ennek [(949968, 'ennek'), (1065, 'ennék'), (235, 'énnek')
905106 eves [(891166, 'éves'), (8590, 'evés')
785259 tudom [(784255, 'tudom'), (870, 'tüdőm')
751650 valo [(720486, 'való'), (17870, 'váló')
734599 szamara [(731460, 'számára'), (2851, 'szamara')

kicsit varialok meg rajta...

( arpi_esp v | 2022. 07. 03., v – 19:13 )

na meg valamit megprobaltam az alternativak eldontesere:  a gyakori szokapcsolatok figyeleset/szamolasat. akar meg jo is lehet:

13474817 meg [(7871162, 'meg'), (5602969, 'még')] és+még de+még jelent+meg hogy+még is+meg akkor+még van+még ez+még halt+meg jelenik+meg

2411835 fel [(1967955, 'fel'), (443783, 'fél')] és+fél hívta+fel is+fel tűnt+fel egy+fél merült+fel lépett+fel lép+fel vette+fel hívja+fel

1058255 akar [(759331, 'akár'), (298813, 'akar')] vagy+akár nem+akar hogy+akár de+akár és+akár mit+akar amit+akar így+akár sem+akar is+akár

910240 hat [(606818, 'hát'), (303181, 'hat')] de+hát így+hát és+hát csak+hát mert+hát meg+hát és+hat első+hat hogy+hát is+hát

836783 hozza [(752160, 'hozzá'), (84496, 'hozza')] tette+hozzá kell+hozzá és+hozzá van+hozzá is+hozzá fűzte+hozzá járult+hozzá teszi+hozzá szólj+hozzá még+hozzá

781362 ot [(397581, 'őt'), (367291, 'öt')] az+öt az+őt hogy+őt és+öt elmúlt+öt első+öt meg+őt hogy+öt és+őt csak+öt

685429 fele [(523681, 'felé'), (117786, 'fele')] vége+felé mint+fele dél+felé kelet+felé másik+fele észak+felé nyugat+felé ég+felé egyik+fele budapest+felé

678141 szinten [(490987, 'szintén'), (186909, 'szinten')] éves+szinten ami+szintén aki+szintén és+szintén napi+szinten pedig+szintén olyan+szinten nemzetközi+szinten egy+szintén valamilyen+szinten

...

84302 kerek [(34590, 'kerek'), (31712, 'kérek'), (17930, 'kerék')] elnézést+kérek nem+kérek bocsánatot+kérek egy+kerek nem+kerek én+kérek nagy+kerek és+kerek szép+kerek segítséget+kérek kis+kerek is+kérek hogy+kerek arra+kérek így+kerek amit+kérek annyit+kérek is+kerek és+kérek volt+kerek türelmet+kérek ezért+kérek hogy+kérek tanácsot+kérek akkor+kérek mit+kérek két+kerek sem+kérek ezúton+kérek olyan+kerek majd+kérek négyszögletű+kerek minden+kerek teljesen+kerek egyet+kérek lesz+kerek csak+kerek hatalmas+kerek meg+kerek az+kerek arca+kerek engedélyt+kérek már+kerek apró+kerek pedig+kerek vagy+kerek kicsi+kerek de+kerek ilyen+kerek úgy+kerek

mondjuk hogy mennyire muxik a gyakorlatban, jo kerdes... TODO-n van egy tesztelo/validalo irasa is, ami uj ekezetes szoveget ekezettelenit, lefuttatja rajta es osszehasonlitja hany %-ban lett jo

( Dhat | 2022. 07. 03., v – 20:55 )

Szerkesztve: 2022. 07. 03., v – 21:00

Lenne egy ötletem másképp indítva:

1) google fordítóval ( biztosan van API ), lefordítani angolra, németre, franciára, spanyolra az ékezet nélküli magyar szöveget ( 4 szálon )

2) aztán az idegen nyelvekről vissza fordítani magyarra

3) ekkor kapunk egy csomó magyar szót immár élkezetesen, és ezekhez hasonlítanánk az eredeti szöveget szavanként 

4) ha nincs találat, akkor több nyelvet is be kellene vonni a rendszerbe, és ha kellően sok nyelvet döntünk be akkor van esély a szó szerinti fordításnak

5) vagy esetleg lehet szavanként fordítani 

hu ez eleg perverz otlet, de miert ne...

kiprobaltam az elso bekezdesen angolra oda-vissza ezt adja:

Mivel ilyen (savanyú) uborkaszezon van, egy régi ötletem támadt: olyan programot írni, ami ékezet nélkül pontozza a szöveget. Valaki csinált már ilyet, hallottam olyanról, aki tud olyat, akinek a nagybátyját is látták valahol az erdőben, de nem találtam.

ez igy nem tul jo, de ha csak a szavakat felhasznaljuk belole es parositjuk az eredetivel, valamennyire meg jo is lehet...

( arpi_esp v | 2022. 07. 03., v – 23:47 )

Szerkesztve: 2022. 07. 04., h – 00:04

megirtam a validatort is. hat ez jobb lett, mint vartam, a v4-es adatokkal lefuttatva, az input kb 100 ujsagcikk szovege:

# wc test.txt
   4557  275081 2177299 test.txt

# ./validate_map.py

1148141 554111
Counters:  ALL=249405  found=128124 (14808 multi)  good=127086  same=117573  notfound=121281
Hits:  1:1=113076 (bad:240)  pair:4251/776 (bad:188)  alternatives:6677/2306 (bad:610)
Stats:      found: 128124  good: 127086  bad: 1038 = 0.810 %
Stats:  not found: 121281  same: 117573  bad: 3708 = 3.057 %
Total:  98.097 %

tehat ha megtalalta a szot a szotarban, akkor az 99.2%-ban jo is volt! egyebkent az egeszre vetitve 98% a pontossaga (mivel sok szot nem ismert / nem talalta meg a szotarban).

az is latszik, hogy a gyakori parok felismerese az esetek 96%-aban jo eredmenyt adott, es az alternativak kozul az elso valtozat 3x gyakrabban jo.

kene egy handpicked file, ahova kézzel is fel lehetne vinni egy egy megoldást, anelkul hogy a tanito szovegben benne lenne.

pl:

ekezesit:ékezesít

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( hory v | 2022. 07. 04., h – 11:27 )

mokazni jo, csak az a baj vele, hogy amikor szlenget ir valaki, vagy elgepel, akkor ez frankon csak tovabb rontja a helyzetet, es meg kevesbe ertheto, hogy mi is akart lenni.

szoval kb. olyan, mint egy autocorrect; tok jo, ha az input megfelelo, amugy inkabb zavaro lenne.

szlenggel szerintem elboldogul, gyakori elgepelessel is talan (persze kijavitani nem fogja csak ekezetet rak ra :)). mivel termeszetes szoveggel van tanitva, ha abban elofordul tobbszor akkor tudni fogja.  jelenleg a tanitashoz kb 1/3-ban forum kommentek mennek, igy van ra esely...

( debiandor | 2022. 07. 04., h – 22:14 )

Nagyon tetszik az 5let és a megoldás is, grat hozzá, részemről idei Ig Nobel dijazottam :D

( mindegy v | 2022. 07. 06., sze – 12:10 )

Tök jó és klassz, hogy megosztottad!

Mintha nemethl foglalkozott volna ilyennel korábban (kétezres évek), talán a Hunspell fejlesztés kapcsán vagy a HunMorph-ot használva. Sajnos nem találtam nyomát, lehet, hogy rosszul emlékszem.

Ez meg egy 2020-as neurális hálós egyetemi tanulmány, kód és demó nem elérhető szabadon, csak a cikk.

koszi, ez erdekes volt.  en is talaltam parat:

http://eprints.sztaki.hu/7875/1/Kornai_1791016_ny.pdf

https://hlt.bme.hu/media/pdf/acs_halmi_2016.pdf

https://github.com/juditacs/hunaccent

kiprobaltam ezt a hunaccent-et, ahhoz kepest hogy nem hasznal szotart csak a kornyezo 4-4 betut veszi figyelembe, nem is rossz, de kisse tajszolas jellegu lett, oda is tesz ekezetet ahova nem kellene:

 

Az eredeti ötletem az volt, hogy neurális hálóvál, szövegkörnyezet alapján word2véc-et felhasználva találná ki, hogy a többféle írásmód közül vajon ott melyikre lehet szükség. Ehhez először is fogtam pár ezer újságcikkét, és összedobtam egy python scriptet (gen_map.py) ami szavánként megnézi a gyakoriságot és a végén kilistázza melyikék azok a szavák, ahol többféle ékezetés alak tartozik ugyanahhoz az ékezet nélkülihéz. A meglepetés akkor jött, mikor lefuttattam (pár bugfix után:)), és kiderült, hogy a szavak kb 90%-ának csak egyfélé alakja van, tehát 1:1 leképzésről van szó. A maradékban viszont nagyon sok olyan van, ahol nem a szöveg témája (ámire a word2vec jó lenne) miatt kell különböző alakot használni, hanem a nyelvtan, pl. ragozás miatt. Így első körben él is vetettem a neurális hálót, nézzük meg csak simán statisztikailag hogy működik!

( arpi_esp v | 2022. 07. 11., h – 15:06 )

Szerkesztve: 2022. 07. 11., h – 15:46

Felraktam egy v5 verziot. Javitva lett az URL-ek kezelese (ne ekezetesitse a domaint :)) es a zarojelek is, uj tokenizalo altal. A validacio eredmenye is javult picit emiatt, amelyik szot ismeri ott mar csak 0.4% a tevedes. Az ismeretlenek jelentos resze is eliras vagy nev volt, vagy olyan ritka szavak mint pl. múzeum-labirintusnak, piacikapitalizmus-barát, orbáni-Alaptörvény, joguralom-követelménnyel stb...  meg annyit lehetne tenni, hogy a kotojeles ismeretlen osszetett szavakat szetbontani es kulon-kulon megnezni.

Counters:  ALL=248957  found=128908 (15108 multi)  good=128399  same=117483  notfound=120049
Hits:  1:1=113557 (bad:243)  pair:4688/795 (bad:192)  alternatives:6993/2366 (bad:74)
Stats:      found: 128908  good: 128399  bad: 509 = 0.395 %
Stats:  not found: 120049  same: 117483  bad: 2566 = 2.137 %
Total:  98.765 %

http://thot.banki.hu/ekezet/v5/

szerk: beleirtam a kotojel-splittelest (ha nem ismeri az "a-b" format akkor megnezi kulon a es b), de nem lett sokkal jobb:

Counters:  ALL=250090  found=129810 (15294 multi)  good=129239  same=118283  notfound=120280  split=1093
Hits:  1:1=114258 (bad:258)  pair:4716/799 (bad:195)  alternatives:7054/2412 (bad:118)
Stats:      found: 129810  good: 129239  bad: 571 = 0.440 %
Stats:  not found: 120280  same: 118283  bad: 1997 = 1.660 %
Total:  98.973 %

Miért nem tanítasz rá egy RF modellt ahogy írtam feljebb feature vektorokkal? Pyhon-ban nagyon könnyű. Nem láthatjuk emberként hogy tud-e találni összefüggést. Vagy tudja javítani az eredményt, vagy nem, de ennél erősebb modell nincs aminél nem kell hiper paraméter tuningolás és érzéketlen a túltanításra:

https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.Rand…

Egy classification problémának tervezném meg így hamar gyorsan. Sajnos pár percnél több időm nincs rá, mint amennyi ideig megírom ezt.

Tehát feljebbi módon csinálsz rengeteg feature vektort. Ezek lesznek a bemeneti változók x1, x2, x3 ... xn néven. A kimeneti válasz egy integer, mely azt mutatja, hogy mennyi ékezet kellene a keresett ékezet nélküli szóba. Lehetne bináris értékbe is pakolni, hogy hányadik magánhangzón legyen ékezet, például az 5-ös értéke 101 bináris, vagy 1. és 3. magánhangzóba kell, de ezt inkább ne egyelőre.

Nincs sok időm rá, én megpróbálnám az ékezetek számát kitaláltatni az AI-al. Tehát a tanító adat így néz ki:

[ y, x1, x2, x3, ..., xn ],

[ y, x1, x2, x3, ..., xn ],

[ y, x1, x2, x3, ..., xn ],

[ y, x1, x2, x3, ..., xn ],

[ y, x1, x2, x3, ..., xn ],

...

Amire pedig kérdezünk, az így néz ki:

[ ?, x1, x2, x3, ..., xn ]

Ennél nyilván csak a választ nem tudjuk.

Az x változók pedig lehetnek:

- szavak közti távolság (https://en.wikipedia.org/wiki/Levenshtein_distance)

- mennyi ékezetes betű van mindegyikben, például ezek összege

- mennyi magánhangzó van bennük

- mennyi mássalhangzó van bennük

- magán vagy mással hangzóval kezdődnek (lehet 0 és 1 érték ez)

meg még ami eszedbe jut. Tele pakolhatnád még egyébbel. Próbálj minél trükkösebb feature-öket létrehozni.

Y változók pedig az ékezetek valós számát mutatják. Kivéve az utolsó sor első oszlopában, aminek mindegy mi az értéke, ezért lehet 0. Ezt akarjuk kitalálni.

 

Tuningolni ne tuningold az RF modellt, nem kell. Ez az egyetlen aminél nincs rá szükség, így nem is vesz el rengeteg időt a kombinációs tér bejárása. Alapból jó teljesítményt fog hozni.

Hogy tud-e segíteni gondolkodni a fenti feature vektorokból, azt nem tudjuk előre.

Írtam neked gyorsan egy példa kódot, ebbe dobáld be amit kell és meglátod milyen válaszokat ad. Előtte "pip3 install scikit-learn":

 

# example data for xor values, firt column is target
# rest is feature vectors, last row is the question
data = [ [0,0,0], [0,1,1], [1,1,0], [1,0,1], [0,0.2,0.7] ]

# separate data as input and target
x, y = [], []
for i, v in enumerate(data[:-1]):
	y.append( v[0] )
	x.append( v[1:] )
x2 = []
for i, v in enumerate(data[-1:]):
	x2.append( v[1:] )

# import model
from sklearn.ensemble import RandomForestClassifier
# select model
clf = RandomForestClassifier()
# train model
clf.fit( x, y )
# ask model
res = clf.predict( x2 ).tolist()

# print result
print( res[0] )

 

( Ez válaszként 1-et ad, mert az áll a legközelebb. )

mert szovegre nem olyan egyszeru ertelmes/hasznos feature vektorokat eloallitani... nem veletlen talaltak ki a word2vec, fasttext stb embedding modszereket. az, hogy hany betu egy szo meg hany maganhanzgo van benne stb, annak nem sok koze van ahhoz hogy hany ekezet kell ra...

valaki amugy belinkelt egy tanulmanyt ahol tobbfele NN modellel megcsinaltak, es nem lett jobb az eredmenyuk mint az enyem.

esetleg betunkenti RNN/LSTM variaciokkal lehetne kuzdeni, de ott meg eleg sok az egyeb hiba, par eve kiserteleztem vele.

ezt az altalad emlegetett forest cuccot nem ismerem, majd 1x megnezem, de igazabol az is csak akkor mukodne, ha ertelmes es hasznos inputot kapna. talan fasttext-el kombinalva mukodne, az szotagokon operal, eleg jol le tudja venni a nyelvek hangzasat, pl. nyelv felismeresre ajanljak mert akkor is felimseri a nyelvet ha az adott szot nem ismeri.

Rossz modellel kísérleteztél. Több ok miatt:

1) hogy mi az értelmes input, az nagyon szubjektív, de emberileg biztos hogy nem eldönthető. Ha van értelmes input, akkor AI se biztos hogy kell, mert hogy számodra értelmes, tehát ember által értelmezhető :)

2) NN esetén nem biztos hogy valaha közel voltál az optimális modell beállításhoz (hiper paraméter tuning) és így lehet, hogy volt egy jó inputod, de nem tudtál rá olyan modellt csinálni, ami képes kibontani a mély összefüggéseket belőle.

Azt kell látni, hogy NN alapú modellek kizárólag big data-nál tudnak jeleskedni, de majdnem csak ott. Ugyanis nagyon érzékenyek a zajra a változók között, illetve hogy normalizáltak-e, érzékenyek az idegi kapcsolat paramétereire (rejtett rétegek száma stb) és iszonyat nehéz megtalálni az optimális modell beállítást.

Ezzel szemben emberiségünk egyik legerősebb modellje RF. Szinte soha nem kell tuningolni, elég érzéketlen a rossz változókra -> ezért lehet bedobálni 100-szor annyit, majd ő kiválogatja - ezt semmilyen más modellel nem tudod megtenni és ez komoly probléma. Ugyanis RF nélkül nem tudod, hogy mi a jó modell és mi a jó input. Így nagyon nehéz.

Viszont RF megoldja, éppen az algója miatt, mivel véletlen mintavételezést csinál mind a feature-ök közül és a mind az adat pontok közül. Iszonyat erős. SZVSZ az egyik legjobb modellünk általánosságban.

Mivel RF megtalálja a választ és a mély összefüggéseket az adatban HA LÉTEZIK, így könnyű a dolgunk. Minél többet bedobálni és készen is vagyunk. Utána már csak mérnünk kell a hatékonyságot. Ezt más modellel nagyon nehéz megtenni. Csupán ezért ajánlottam.

Ha most nincs időd, abszolút érthető, de ha AI modellhez nyúlsz, akkor RF-el kezd.

na kiprobaltam ezt az RF-et, elsore tenyleg nem rossz. de a fent linkelt hunaccent pdf-ben leirt inputra kuldtem ra, ok vegul decision tree-t hasznaltak de probaltak mas classifiert is.

ennek a lenyege, hogy a keresett karakter elotti es utani 4-4 betu az input, az output pedig, hogy kell-e ekezet a vizsgalt beture. ok minden maganhanzgora kulon modelt tanitottak es mindig a megfelelot hasznaltak. en egyelore csak az 'a'-ra epitettem eleg keves adatbol (naluk 2M input volt, nalam most csak 162290), es 1640-et felretettem tesztre:

37 1640 2.2560975609756095

ebbol csak 37x hibazott, ami 2.25%, egesz jo igy elsore, es keves inputbol. megnezem majd nagyobb inputtal is, de elobb belerakom hogy a tobbi maganhangzot is ismerje...

ilyen inputokat kapott az RF:

y: x:
0 [118, 97, 110, 32, 97, 32, 109, 117, 110]
1 [109, 117, 110, 107, 97, 110, 32, 97, 32]
0 [107, 97, 110, 32, 97, 32, 110, 121, 105]

a szamok a lowercase ekezettelenitett ascii kodok a vizsgalt karakter korul +-4

meglatjuk, ha eleg igeretes akkor meg lehet boviteni a feature vektorokat, csak valami okosat kell kitalalni aminek ertelme is van :)

Jól hangzik :) Pont az a szuper RF-nél, hogy teledobálhatod sok feature vektorral, míg a többi modell leromlik, ez nem igazán.

Ettől a ponttól kezdve a feature engineeringen (FE) fog múlni a teljesítmény. Bármit is dobálsz be, ha van összefüggés, megtalálja.

További FE-re ötlet:

A betett vektorok egymás közötti szorzata, összege és különbségük abszolút értéke is bemehetne, nem baj ha szorozza a számukat - persze nem érdemes elrobbantani a számukat, mondjuk jó lenne ha 30 vagy legalább 100 alatt maradna az összes - tapasztalatom alapján ez a pár alap művelet elég, mert már megnyitja akkorára a kombinációs terét az összefüggéseknek, hogy a regressziós elemzésnek elégséges - tehát nincs szükség négyzetre, gyökre és hasonlókra

Hogy ne mindent mindennel kelljen összehasonlítani, lecsökkenthető az elrobbanó kombináció úgy, hogy determinisztikus módon összekevered az X-eket minden sorban ugyanúgy, és a szomszédos X-ek között csinálod a műveletet (összeadás stb). Ezzel csak 3-szorosára nő az X-ek száma a 3 művelet miatt, nem lesz négyzetes. A keverés azért fontos, hogy dolgozni tudjon a véletlen eloszlás és a nagy számok törvénye jól ossza szét a műveleteket.

Illetve amiket írtam feljebb FE-ket is megcsinálhatnád ha lesz rá időd.

Lehetne szó kezdetről csinálni FE-t és a végéről is. Például magánhangzók és mássalhangzók aránya.

Illetve lehetne egy csökkenő súlyozás a betűk típusára normál és fordított szóra is, mely így a szó kezdetére és végére is ad egy szempontot. Például úgy, hogy nullának vesszük a mássalhangzót, és 1-nek a magánhangzót, majd minden szónál úgy csinálod ezt a pontozást, hogy végig mész a betűkön és a pozíciójuk köbét veszed súlynak és súlyozott átlagot számolsz. Nézzük az alma szót:

0. index = a betű, tehát értéke 1

1. index = l betű, értéke 0

2. index = m, értéke 0

3. index = a, értéke 1

Súlyozott aritmetikai átlag:

( 0^3 * 1 + 1^3 * 0 + 2^3 * 0 + 3^3 * 1 ) = 27

ez osztva a súlyok összegével:

( 0^3 + 1^3 + 2^3 + 3^3 ) = 36

eredmény:

0.75

Így egy balanszot kapunk a szavakban a mással és magánhangzók eloszlásáról. Lehet hogy segít, lehet hogy nem.

Meg ilyenekkel kellene teletenni, aztán a 3 műveleti kombináció, és úgy ráengedni :)

hat innentol ugye vegtelen lehetoseg van, amit vegtelen ido vegig kiserletezni. szerintem en ezt most elengedem...

altalanossagban igaz minden MI-re, hogy minden a feature vektorokon mulik, ha azok nem jok az eredmeny se lesz jo. nincs ez itt se maskepp. max annyi hogy a nem jok kevesbe zavarnak be, de attol meg amig a jokat nem talalod meg, nem fog mukodni...

en 5-6 eve foglalkozok NLP-vel, es a text -> vektor mindig a legnagyobb problema, avagy szovegbol feature vektorokat csinalni. rengeteg publikacio van a temaban, szerintem mar minden letezo es vad otletet kiprobaltak az evek soran...
nagyon meglepne ha a betuk ascii kodjanak szorzata meg hasonlo baromsagok barmit is javitana ezen... akkor mar mas is rajott volna...  a mai napig a word vectorok (glovec, word2vec, fasttext es tarsaik) a legjobb input NLP-hez.

amugy rakuldtem kozbe nagyobb inputra is, hat...

0 17620405 17620405 927390 927390
0 9153 927390 0.9869634134506519%
1 18300380 18300380 963178 963178
Killed

17 millio inputbol kihozott 0.98% hibat (baromi lassan), de aztan el is crashelt OOM-el, pedig van neki 32GB ramja.

lekorlatoztam 2 milliora, ugy meg a pontossag is felezodott, a 2% hiba mar nem annyira jo (a szotaras verziom 0.4% hibazik):

0 2000000 2000000 16547795 16547795
0 318180 16547795 1.9227939432413805%
1 2000000 2000000 17263558 17263558
1 338646 17263558 1.961623438227508%
2 2000000 2000000 5519656 5519656
2 20677 5519656 0.37460667838720385%
3 2000000 2000000 8674317 8674317
3 215895 8674317 2.4888991260061166%
4 2000000 2000000 1125077 1125077
4 16418 1125077 1.4592778983127377%

csak erdekessegkepp lefuttattam ugyanezt DecisionTree-vel is, kicsit szarabb is lett:

0 2000000 2000000 16547795 16547795
0 399101 16547795 2.411807736317739%
1 2000000 2000000 17263558 17263558
1 452216 17263558 2.6194831911243326%
2 2000000 2000000 5519656 5519656
2 32564 5519656 0.5899643021231757%
3 2000000 2000000 8674317 8674317
3 310305 8674317 3.5772845285686468%
4 2000000 2000000 1125077 1125077
4 25029 1125077 2.2246477352216782%

Kicsi rá az esély hogy másik modell jobbat adjon.

Persze hogy végtelen a kombinációk száma, de alap dolgok összerakhatók. A hangzók eloszlása és azokkal kapcsolatos egyéb jelzők nem butaságok, segíthetik a döntést. Mikro hatások lehetnek melyek összeadódnak. Ezért kell a szofisztikáltság.

Egyszerű input-tól nem várhatsz sokat. Azt meg nem tudod, hogy milyen összefüggések léteznek csak az általam felsorolt feature-ökben. Elemzés nélkül ez nem eldönthető. És igen, ez is munkás, megtervezni, leprogramozni a feature-öket, tesztelni, újat tervezni és újra tesztelni.

BTW hipotézis teszttel kell vizsgálni, hogy van-e szignifikáns hatás.

Ha csak 0 és 1 kimenet van és a teljes számuk N, akkor a hatás vizsgálathoz az eltévesztett döntéseknek kisebbnek kell lennie mint ( N/2 - N^0.5 ) értéke. Erős a hatás ha kisebb mint ( N/2 - N^0.5 * 1.5 ).

( arpi_esp v | 2022. 07. 12., k – 20:29 )

arra van valakinek otlete, hogy lehetne irni olyan bongeszo plugint, ami mondjuk a kijelolt szoveget jobbclick (context menu) opcioval meghivna ezt a programnot (akar ajax-al egy szerverrol mint web service) es kicserelne a kijeloltet az outputra?

Context menut nem tudok. Regen (meg mukodott a XUL FF-ban) irtam olyat, ami bizonyos form elemek melle kitett gombokat/kepeket, ami klikkre elkuldott a helyi serverre adatot (es a valasz alapjan kitoltotte tartalommal).

Most is inkabb ezen az uton indulnek el, jellemzoen textarea-ban, esetleg sima szoveges input mezoben kellene ugyis mukodnie, amelle kitennek DOM-bol egy kepet, aztan a tobbi mar csak ajax kerdese. De az uj extension rendszert nem ismerem (ez meg 1.5-2.0 korul volt). Az uj elvileg kicsit maskepp mukodik, viszont a Chrome-hoz jobban hasonlit, szoval ha megirod az egyikre, az a masikra is jo lesz.

A strange game. The only winning move is not to play. How about a nice game of chess?

Lehet ilyet, de nem plugint, hanem extension-t. A browserpluginoknak az NPAPI kinyírásával vége.
A context menübe fel lehet venni új entry-ket (az adblockerek pl. csinálják is) és lehet website felé is AJAX lekérést küldeni extensionből (csak a manifestbe kell, hogy

"permissions": [
	"webRequest",
	"<all urls>"
],

), meg lehet külső programot is meghívni, pl. króm alatt FileIO-val, róka alatt meg native messages-szel.

Oldschool Computer - http://oscomp.hu

talaltam egy ilyet, kiindulasnak egesz jo. debuggerben betoltottem, muxik. van context menu entry is.

http://www.mattduck.com/a-super-dumb-web-highlighter.html

bar most latom hogy pont a text editor ablakban nem muxik, csak a fenti szovegekre :(

az ajaxot meg beleirom valahogy, kerdes, hogy a szoveget hogy lehet kicserelni? illetve akkor valoszinu kimasolni se igy kene?

    const sel = document.getSelection();
    alert(sel);

Tekintve, hogy a kijelölt szövegben akár formázások is lehetnek, a másolás meg plaintext, lehet jobban járnál egy olyan megoldással, hogy átmegy a pointer crosshairbe, ráböksz a "root" elementre, amit ékezetesíteni akarsz, végigiterál rajta rekurzívan (.childNodes[].childNodes[].childNodes[]...) és az .innerText property-ket küldi el ékezetesítésre, aztán vissza is írja. Így a formázás is megmarad.

Oldschool Computer - http://oscomp.hu

azt majd a v2.0-ban :)

kezdjuk ott hogy total kezdo vagyok JS-be, bongeszo API-val meg sose foglalkoztam, azt se tudom merre kene indulni. nezegetek mas extensionokat, de egyelore meg olyat se tallatam, ami mukodne a hup szerkeszto ablakaban...

szoval en mar annak is orulnek ha valahogy sikerulne a kijelolt szoveghez hozzajutni, plane ha modositani is...

google meg 2001-es meg hasonlo talalatokat ad getSelection + textarea keresesekre, amivel nem sokra megyek :(

Ha csak simán a kijelölt szöveg kell plaintextben, azt így megkapod:

function getSelText()
{
	return window.getSelection ? window.getSelection() : (document.getSelection ? document.getSelection() : (document.selection ? document.selection.createRange().text : ''));
}

Ha a kijelölt szöveg root HTML node-ja kell, annak minden alelemével és egyebével, akkor

function getSelHTML()
{
	if (document.selection && document.selection.createRange)
	{
		return document.selection.createRange().cloneContents().firstChild;
	}
	else if (window.getSelection)
	{
        	var sel = window.getSelection();
		if (sel.rangeCount > 0)
		{
			return sel.getRangeAt(0).cloneContents().firstChild;
		}
		else
		{
			return null;
        	}
	}
	else
	{
		return null;
	}
}

Módosítani csak az utóbbival fogod tudni, úgy, ahogy az előző kommentben leírtam:

function iterate(node)
{
	var i;

	for (i = 0; i < node.childNodes.length; ++i)
	{
		if (node.childNodes[i].innerText)
		{
			node.childNodes[i].innerText = ekezet(node.childNodes[i].innerText);
		}
		iterate(node.childNodes[i]);
	}
}

Ez utóbbit most csak "fejből" írtam és nem teszteltem le, de - hacsak el nem basztam valamit - így kell, hogy menjen.

Oldschool Computer - http://oscomp.hu

igen ezt probalgatom mar orak ota, de sajnos ez szerkeszteskor (textarea-ban) nem mukodik...

nekem se, es mozillaek szerint se:

https://developer.mozilla.org/en-US/docs/Web/API/Window/getSelection

It is worth noting that currently getSelection() doesn't work on the content of <textarea> and <input> elements in Firefox, Edge (Legacy) and Internet Explorer. HTMLInputElement.setSelectionRange() or the selectionStart and selectionEnd properties could be used to work around this.

na most nekem a selectionStart/selectionEnd is mindig 0, akkor is ha megkeresem byId a textarea objectet es abban nezem :(  viszont a value-ben ott a szoveg, viszont modositani se tudom...

Ja, hogy textarea-ba replacelni? Akkor így:

function ekezetTextareaSelection(textarea)
{
	if (document.selection)
	{
		textarea.focus();
		var sel = document.selection.createRange();
		sel.text = ekezet(sel.text);
	}
	else
	{
		if (textarea.selectionStart || textarea.selectionStart == "0")
		{
			var sel = ekezet(textarea.value.substring(textarea.selectionStart, textarea.selectionEnd));
			textarea.value =
				textarea.value.substring(0, textarea.selectionStart) +
				sel +
				textarea.value.substring(textarea.selectionEnd, textarea.value.length)
			;
			textarea.selectionEnd = textarea.selectionStart + sel.length;
		}
		else
		{
			textarea.value += szijjagazt;
		}
	}
}

Ezt sem teszteltem, csak átírtam egy működő függvényemet, ami beszúr a textarea-ba a kurzornál.

Apropó, itt van nekem egy extension-öm, az első (és az utolsó), amit írtam, nem reklámoznám a kódját, de működik, szóval nyugodtan felhasználhatod a keretét a sajátodhoz. (Public Domain)

Oldschool Computer - http://oscomp.hu

koszi, majd megnezem. de nekem a textarea.selectionStart is mindig 0, hiaba van kijelolve valami... a .value-be pedig ott a text.

egyelore kezdem elengedni ezt a getselection dolgot, a kiolvasas se akar mukodni, a modositas meg plane. egyszeru static html formban jo, de pl. a hup-on mar nem, lehet a fancy editor miatt. atirom a textarea value-t, ha kiolvasom az atirtat kapom, de az ablakban nem modosul a szoveg...

atterek inkabb mas koncepciora, a clipboard tartalmat fogom filterezni, azaz kijeloles utan kell egy ctrl+c, egy gombnyomas (egyelore contextmenube van egy valami ami meghivja a fv-t) ami modositja a clipboard tartalmat aztan ctrl+v...

A hupon a fancy editor igazából egy iframe, aminek szerkeszthető a tartalma. Arra a fentebb becopyzott getSelHTML() függvényemet kéne meghívni, csak a document-et, meg a window-ot iframe.contentDocument-re és iframe.contentWindow-ra cserélni.

Oldschool Computer - http://oscomp.hu

na jó ez nekem már kínai...  összegányoltam annyira, hogy a vágólapra rakott szöveget átfuttatja a filteren (ajax fetch() hívással egy cgi-re), és visszaírja a vágólapra. ez így műxik. firefoxban biztos, máshol nem próbáltam...

http://thot.banki.hu/ekezet/ekezetesito.zip

itt lehet beölteni, a manifest.json-t kell kitallózni a load temorary addon-al:

         about:debugging#/runtime/this-firefox

használata:

1. szöveg kijelölés

2. ctrl+c

3. ctrl+shift+L vagy jobbclick context menüből ekezetesito menüpont (alert()-el is mutatja az eredményt)

4. ctrl+v

nekem ennél jobban nem megy, nem is erőltetem :)

ha van kedved megnézheted, miért nem megy a selection kiolvasás, akkor egy ctrl+c megspórolható lenne...

közbe találtam egy olyan ext-et ami tudja amit kell:dictzone szótár. kijelölöd, context menü és már fordítja is. ez alapján átírtam az extensiont, mostmár nekem is így mux :)  legalábbis már nem kell vágólapra másolni és onnan kiolvasni, elég kijelölni. de az eredmény még a vágólapra megy... ami nem is akkora baj.

http://thot.banki.hu/ekezet/ekezetesito.zip

a formázást elcseszi persze, mert így nem a html hanem csak a text megy át, de nem érdekel, úgyse szoktam formázni, vagy max az ekezetesites után...

a szerveroldalon kell még reszelnem, a sima py cgi-t átírni wsgi-re, hogy ne töltse újra a db-t minden requestnél, de azt már megoldom.

sőt azóta átírtam, hogy az extensionben van json-ba a 2 db, és javascriptben a parser/tokenizer, így nem is kell ajax meg külső szerver hozzá...  a kötőjel felbontást még nem raktam bele, de amúgy nagyjából ugyanazt csinálja mint a python verzió

http://thot.banki.hu/ekezet/ekezetesito.zip

fingom sincs, de mind2 lefut kb 0,01 sec alatt :)

meg lehetne nézni valami bazi nagy szövegre de kérdés egyáltalán a böngésző átviszi-e azt a mennyiséget, meg kéne bele timert is rakni akkor... fölösleges ezt sebességre nézni sztem

megtalaltam en is, meg is probaltam feltolteni nekik, de viccesek a sracok:

 

File is too large to parse.

Hiba: This file is not binary and is too large to parse. Files larger than 4MB will not be parsed. Consider moving large lists of data out of JavaScript files and into JSON files, or splitting very large files into smaller ones.

wordmap.json

 

https://github.com/mozilla/addons-linter/issues/3680

csinaltam .xpi filet is belole, de azt se engedi telepiteni, mert unsigned :)

Modern korunk modern browsereinek modern gyönyörei... Elég szomorú, hogy 4 MB 2022-ben túl nagynak minősül, meg az is, hogy eldönti a felhasználó helyett, hogy mit telepíthet fel a saját browserébe. (Az meg pláne, hogy ezt a marhaságot hónapok óta képtelenek javítani.)

Elméletileg, ha az about:config-ban az xpinstall.signatures.required-et hamisra bököd, akkor engedi telepíteni. Nálad legalábbis. :P
Amúgy fel kéne rakni a jpm-et az npm-mel és utána jpm sign --xpi ekezetesito.xpi --api-key="user:12345:67" --api-secret="bazihosszúhexaszám" csak ehhez előbb regisztrálnod kéne magad a Mozillánál. Egyébiránt mások nem fogják tudni felrakni, hacsak nem kapcsolják ki az aláíráscsekkolást. Gondolom a self-signed túl egyszerű lett volna nekik.

Oldschool Computer - http://oscomp.hu

na épp most jött a mail, hogy approved. de közbe írtam már új verziót belőle :)

ez a json betöltés nem volt túl gyors, és fölösleges is 40MB-nyit behúzni pár szó miatt, ráadásul az egy csökkentett méretű szótár volt eleve, meg amúgy is binárist akarnak...

hát kitaláltam gyorsan egy bináris fastrukturas dict file-formátumot, py-ból kigeneráltam, js-be megírtam a fa bejárást... ráment egy délután de sztem jó lett. 10x gyorsabban tölti be (mivel nem kell jsont parsolni, csak a bináris datát beolvasni ahogy van).

mondjuk a kod gusztustalan, orulni fognak akik approvoljak, mar ha ezt megnezi human eroforras egyaltalan...

http://thot.banki.hu/ekezet/content.js

Hogy néz ki belülről a fa?

a-+
| l-+
| | ak
| | ma
| tom
b-+
  a-+
    j
    k

Így kb? És az offset mondja meg, hogy honnan folytatódik a következő ág?
12 bit elég lesz amúgy a karakterkódokra? Nem tudom, mit hova mappeltek az unicode-ban, de mi van, ha X nyelv ékezete kívül esik a 0-4095 tartományon? Vagy ez magyar-only?

Oldschool Computer - http://oscomp.hu

igen, a faban karakterenkent egy pointer (offset) van a subtree-re, vagy ha a subtree mar kicsi akkor egy dict (ezt 0xFF jeloli), ami string-parok egymas utan.

hat egyreszt ez az extension magyar-only. de elvileg boven befer az osszes elo nyelv (latin, cirill, gorog) abc-je ebbe, folotte max rovasiras meg matematikai szimbolumok meg emojik vannak...

https://en.wikipedia.org/wiki/Unicode#Standardized_subsets

nyilvan at lehet irni nagyobb kodokra, ha kell, de mar a tanitasnal is ez a szuro, szoval a kozelebe se leszek a 12 bitnek:

def isalpha(c):
    if c in "-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz": return True
    if c in ',.!?:;/()[]{}„”‘’“–»«': return False
    return ord(c)>=192 and ord(c)<688  # 0x21F

Értem. Ettől függetlenül nem gyorsítana valamit rajta, ha a feles byte-on a tologatás/maszkolás megszűnne, mert az offsetet 28 helyett 32, a kódot meg 12 helyett 16 biten tárolnád? Vagy amennyit a műveleten nyernél, elbukod a plusz adatmennyiségen?

Oldschool Computer - http://oscomp.hu

eredetileg úgy volt, hogy 16 bit charcode és 32 bit az offset. mivel a file nagy részét ilyenek tették ki, csak poénból kíváncsiságból kipróbáltam, hogy ha 1 byteot spórolok itt akkor mi lesz, mivel offsetre éppen elég a 28 bit (a 24 kevés) és unicodera is elég a 12. viszont a file méret így 10-12% kisebb lett, ami 44 megánál nem mind1.

a sebesség meg kb mind1, nem ezen múlik úgyse, és ezt fölösleges nagyon optimalizálni, mivel csak pár lookup van összesen.

a file-méret sokkal fontosabb, nem mind1 mennyi memóriát foglal, mennyi idő alatt tölti be (mivel minden oldalbetöltésnél újra kell tölteni...). inkább még|meg agyalok hogy lehetne tovább tömöríteni :)

az offseteknel lehetne valami RLE szerű kódolást csinálni relatív offsetekkel, de mivel előre le kell allokálni a helyét ez így macerás lenne, vagy az egész file formátumot át kell variálni hozzá. lehet az lesz amúgy.

lehet, kérdés lehet-e a backgroundban is bármit csinálni? mi van ha ott lesz exception? hogy küldök a contentbol oda adatot? a másik irányt láttam eddig csak stb.

inkább optimalizáltam még a fileformatumon, beleraktam az RLE kódolást a hosszakra (sőt a leggyakoribb 12 hosszt belezsúfoltam a karakterkód felső 4 bitjébe:)) meg kioptimaltam még pár fölösleges bitet a dict körül (azt meg a leaf node hosszába dugtam el), így még 10%-al kisebb lett.  innentől már max úgy lehetne csökkenteni, ha elkezdem mondjuk huffman kódolni a stringeket... vagy mondjuk csak az ékezeteket tárolom le, a betűk nélkül :)

http://thot.banki.hu/ekezet/mktree9.py
http://thot.banki.hu/ekezet/content.js

Mindkét irányba mehet üzenet, itt van példa odafelé is, meg visszafelé is.

Impresszív, amit kihoztál a zsugoríthatóságból, de IMHO tényleg jobban jársz, ha inkább csak egyszer tölteted be a háttérben. :)

Oldschool Computer - http://oscomp.hu

kösz, majd megnézem.

addigis implementáltam az ékezet kódolást bitekben :)  aeiou karakterek esetén 1 vagy 2 bitben tárolja, hogy milyen ékezet kell rá, max 14 bit terjedelemben. ha ebbe nem fér bele, vagy más fajta ékezet/karakter is van benne akkor marad a sima utf8 string. de a szótár 99%-a belefér ebbe, és így 41 megáról 16-ra csökkent a fileméret! :)

(és vszínű még tovább csökkenthető, mert a gyakori blokkméreteket újra kell számolni, vszínű változott, meg lehet a subtree méret korlátból sem a 12 már az optimális...)

ha nem fix 14 biten (a 2 flaggal együtt 2 byteban), hanem 5 vagy 13 biten (1 bit jelzi melyik) tárolom, akkor még 1 megával csökkenthető, de az eléggé elbonyolítja a keresést is, annyit nem ér...

Hát gondolom, ez az izgalmas része, hogy mennyit lehet még rajta összenyomni... :)

Egyébként, mi történne, ha a karakterkódot nem fix szélességen tárolnád? A betűk többsége egy byte-os. 7. bit 0: ASCII, 1: read extended bits; mennyit csökkentene úgy?

Oldschool Computer - http://oscomp.hu

kb semennyit, mert most is utf8-ba van, az kb ugyanezt csinalja (elso 7 bit ascii, a 8. bit jelzi ha nem az es akkor jon a tobbi byte)

meg mar alig van szoveg benne, mert az input (key) az a fa strukturat adja, az output meg az esetek 99%-ban csak biteken jelzo hova kell ekezet...

amúgy is ékezet nélküli 7 bites a string amire keres (a key a dict-ben), az eredmény meg már csak biteken van tárolva differenciálisan...

sikerült leküzdeni 14.2 megára, kis RLE tweakelessel, de sztem itt a vége, innentől már csak valami entropy coding (pl. huffman) segíthet. de legalább már nagyon gusztustalan a kód, de még is érdemlik a mozillás humán reviewerek :)

http://thot.banki.hu/ekezet/content.js

megnéztem a subtree dict méreteket is, 6-32 végigpróbálva 9-10 a legjobb, alatta/fölötte már nagyobb. úgyhogy most 10 lett.

ahhoz képest, hogy a python pickle file 64 mega, a .json 72, az utf8-as bináris fa 41, nem rossz a 14 :)

Mondjuk, még ha meg is oldod az egyszeri betöltést, akkor is megérte lezsugorítani, mert annyival kevesebb helyet foglal en-bloc és annyival kevesebb sávszélt fog majd, amikor letöltik.

Az RLE-nél olyan sok olyan blokk volt, aminek 255-ös kódja/>64k-s hossza volt, hogy erre szükség volt? A mozzarellásokat meg ne sajnáld, tényleg megérdemlik azok után, amit a rókával csináltak. :/

Oldschool Computer - http://oscomp.hu

hat igazabol onnantol kezdve hogy a binaris fileom mukodott, nem sok ertelme volt a tobbi optimalizalasnak. nem is azert csinaltam, csak just for fun, avagy mint kihivas, meddig lehet egy egyszeru JS dekoderrel megoldani a meretcsokkentest. amugy se sokat kodoltam eddig JS-ben, jo volt gyakorlasnak is. meg amit kevesen tudnak, hogy en 30 eve tomoritoket irtam, eloszor C64-en aztan PC-n is, pl. az ESP akkoriban eleg ismert volt, es honapokig vezette az avtest ranglistat is. gyorsabban es jobban tomoritett mint a zip/arj/rar/stb... igaz honapokig optimalizaltam asm-ben :)

Igen, ez látszott, hogy kedvtelésből megy. :)
A tömörítőidet speciel én sem ismertem: a 90-es évek elején C64 már nem, PC még nem volt nálunk; nem szerepeltek valamelyik CoV-ban? Az ESP-et megtaláltam, a C64-es megvan még valahol?
Egyébként a "tomoritoket" elsőre sikerült "tömörítőkét"-nek olvasni, szóval asszem jó, hogy lett ilyen ékezetesítő program. :)))

Oldschool Computer - http://oscomp.hu

cov nem hiszem, a chip magazin írt az esp-ről asszem, meg cd-n is rajta volt a 90-es években...

c64... akkor még azt se tudtam, mi az az internet, olyan rég volt :) floppyn biztos megvan de hogy beolvasható-e még? passz...

egyszer pár lemezt "digitalizáltunk" pc-re de azt se tudom már hova|hová tettem, az is még a dos-os korszakban volt...