sinexton blogja

Egy szoftver felületén több időbeli számsor (például percenkénti pulzus, edzésenkénti kalória fogyás, futási sebesség) jellemzését 2 értékkel jelölik: átlag és maximum érték. Ide nagyon hiányzik egy harmadik. A jellemző felső érték.

Terveztem egy eljárást két szöveg hasonlóságának vizsgálatára. Gyorsabb mint a Levenshtein távolság (lineáris időben fut) és más karakterisztikákkal rendelkezik. Előbbihez lásd:

https://en.wikipedia.org/wiki/Levenshtein_distance

Írtam arról korábbi blogomban, hogy nagyon hatékonynak tartom futó kódok belső változóinak állapot terét vizsgálni intelligens modellekkel. Kvázi egy élő szemantikai debug, melyet másképpen nagyon nehéz lenne felderíteni, főleg emberként. Nézzünk egy példát minta kóddal (Ruby):

Illusztráció (forrás)

Módosítottam az előző demo-t az algo-m további stressz teszteléséhez:

Több véletlen nagyságú és helyzetű bolygó van egy 2 dimenziós térben. Egy kiindulási pontból elhajítunk egy követ adott erővel és iránnyal. Kérdés:

Milyen erő és irány adja azt a röppályát, mellyel minél több és minél nagyobb bolygóhoz kerül minél közelebb a kő az útja során, mielőtt becsapódik vagy mielőtt eléri a véges számú lépést (repülési időt).

Komplex feladat felfoghatatlan kombinációkkal. Pár kép az optimalizáló eljárásom által talált optimális röppályákról, melyet erősen bonyolít, hogy folyamatosan hat az összes bolygó vonzása:

Az alábbi videóban bemutatom az optimalizáló eljárásom megoldás keresését egy két dimenziós szimulációban, ahol véletlen módon elhelyezett és nagyságú bolygók között elhajított követ kell célba juttatni, miközben a bolygók vonzása rángatja ide oda.

Komplex feladat megtalálni a jó megoldást.

Előző vonatkozó bejegyzés: https://hup.hu/node/180138

Sokszor van szükségem statisztikai eljárásoknál görbe vagy más néven függvény illesztésre. Cél, hogy megtaláljuk, egy függvény milyen paraméterekkel illik mintavételezett értékekre. Ha ez meg van, akkor célzott következtetéseket vonhatunk le a jövőre vonatkozóan. Ennek hatékonysága függ az illesztés hibájának mértékétől.

Pontosabban és testre szabottabban számítom magamnak automatikusan a gépem minimum várható hátralévő idejét. Hasonlóan, mint amit E-autókhoz írtam. Ahogy telik az idő, úgy lesz egyre pontosabb és felhasználási módra hajlított.

Miért nem jó a rendszer által kijelzett érték? Mert engem a hosszabb távon várható érték érdekel. Ha például elviszem magammal a gépem és úton kell dolgoznom, akkor látni akarom hogy nagy eséllyel minimum mennyi munkára elég az én szokásaimnak megfelelően. Kulcsszó a minimum. Mely ha túl kevésre csökken, akkor korábban kérek akksi cserét, növelve ezzel a kiszámíthatóságot.

Ruby script folyamatosan fut és csak 5 percenként terheli minimálisan a CPU-t. Bármikor megszakítható, tudja folytatni a pontosítást a mentett adatokból. Suspend mellett is jól működik.

A gyakorlati problémák felírhatók sok ismeretlenes egyenletként, melyek az ismeretlen faktorok közti összefüggéseket írják le. Nem tudjuk viszont sok esetben, hogy milyen értékek adják a legjobb megoldást.

Fejlesztek egy genetikai algoritmust, mely Monte Carlo szimulációval megtalált paraméterek hibáját konvergálja tovább nulla felé.

Első rész: https://hup.hu/node/179099

Rövid leírás:

Univerzumunkban nincs nulla és 100 százalék esély a jövőbeli eseményekre vonatkozóan. Ezért az extrém értékek előfordulása sohasem nulla vagy 100%. Ezért számolnunk kell vele. Legyen az heti papír fogyás egy cégnél, napi költség az értékesítők üzemanyagára és rengeteg hasonló. A kérdés az, hogy mekkora pufferrel tervezzünk? Vagyis mennyi pénzt különítsünk el különböző dolgokra adott idő nagyságra maximálisan?

Használok anomália detektálást izolációs erdővel felhős infrastruktúra belső analitikájának figyelésére. Ráadásul nyers szöveges részeket is beleteszek. Az automatikus feature engineering megoldásom szétszedi numerikus mátrixra. Majd kiválogatja és szól ha valami furcsa van a múlthoz képest.

Megosztok egy nehéz feladatot, mely ártatlannak és könnyűnek tűnik első ránézésre. Ráadásul egy nagyon gyakorlatias dologról van szó, mert a költség csökkentés mindig fontos része a céges működésnek.

Feladat:

Csökkenteni meglévő költségeket súlyozással úgy, hogy az összegük egy célérték legyen, mely kisebb a jelenlegi összegüknél.

Feltételek:

Mindegyik költség típus csak csökkenhet vagy azonos maradhat és nem lehet negatív. Tehát az eredeti érték és nulla közé kell esniük végül. Ismerjük a fontosságukat, mely egy súlyozott értékként jelenik meg, mely matematikailag vagy más módon került kiszámításra.

Fórum fejlesztők és üzemeltetők figyelmébe szeretném ajánlani, hogy egy érdekes feature lehetne a fórum motorban az, hogy szavazásoknál a legtöbb szavazatot kapó opciónál jelölve lenne, ha statisztikailag szignifikáns módon nagyobb a többi szavazathoz képest és így elégséges a bizonyíték arra nézve, hogy van különbség a szavazó tárborok mérete között.

Ez azért lenne fontos, mert ha nincs vizsgálva szignifikancia és a számok közel vannak egymáshoz, akkor nem jelenthető ki egyértelműen, hogy a nagyobb érték tényleg a nagyobb többséget mutatja.

Például ha összesen 30 szavazat van és a 2 opcióból az egyik 11-et mutat, a másik pedig 19-et, akkor még nem állapítható meg, hogy a 19-es opció mutatja a nagyobb többséget. Ehhez 21 vagy nagyobb érték kell. Ez azért van, mert materiális valóságunkban minden folyamatosan rezeg, fluktuál és így mindenben van valamekkora mértékű bizonytalanság. Statisztikailag viszont ez kizárható “elég” erősen adott esetben.

Néha kellhet vizsgálnunk számsorokat, például költséggel vagy egyéb privát vagy céges adattal kapcsolatban. Ilyenkor hasznos tudnunk, hogy honnétól számít extrémnek egy érték. Mennyi a túl sok?

Ilyen számsorokra lehet példa napi, heti vagy havi felbontásban:

- gyártási hibák száma

- rezsi költség mértéke

- étel költség

- fogyott nyomtatópapír mennyisége

- képviselők által vezetett km

- ügyfélhívások száma

...és így tovább.

Mi az értelme? Ha extrém érték jelenik meg, akkor az azt jelenti, hogy a szokásostól eltérő hatások játszottak szerepet és beavatkozásra lehet szükség.

Elektromos autóknál általában a hatótáv az egyik legfontosabb szempont a használói számára. Viszont tudjuk, hogy a hatótáv erősen függ a használat módjától és helyétől. Befolyásolja az időjárás, például szél iránya és erőssége, lejtők iránya és nagysága, forgalom ingadozás, dugók és millió másik rezgés, illetve hogy mi éppen hova megyünk.

Ezért érdemes lehet matematikai segítséggel pontosítani a hatótáv mértékét testre szabottan a használója számára. Ebbe mindig minden környezeti hatás bele lesz kódolva adaptívan és egyre pontosabb képet fogunk kapni.

Egy vadonatúj gépi tanuló eljáráson dolgozok, mely már készen van és most tesztelési fázisban vagyok. Ismereteim alapján teljesen új a megközelítésem.

1995, a véletlen erdő (Random Forest) megjelenése óta nem született olyan polcról levehető azonnali megoldás IMHO, mely relatíve kevés vagy alap beállításokkal erősen alkalmazható lenne általános esetben, illetve kevés adatnál is. És melynél nincs sok érzékeny hiperparaméter, melyek optimális beállításai nehezen megismerhetők.

Végeztem segítséggel a várásomban elérhető összes hipermarket összes toalettpapír kínálatának elemzésével. Ez 7 üzletet jelent (Aldi, DM, Euro Family, Lidl, Penny, Spar, Tesco) és 90 vizsgált terméket.

Laponkénti egységárra visszaszámolva a termék értékét (mennyi wc papír lapot kapunk 1 forintért) az jött ki, hogy a legjobb ár-értékű termék 7.9-szer olcsóbb a legrosszabbnál. De ha véletlenszerű kiválasztást vizsgálunk (átlaggal osztjuk a legjobbat), akkor is 2.3-szor olcsóbb. Ezt nem tudtuk volna tippelni.

Nagy a szórás a papírtörlő termékek tulajdonságaiban és áraiban. Megosztom veletek elemzésemet. Legfelül vannak a legjobb termékek ár-érték szempontjából. Ezeket érdemes venni!

Hamar kellett JS-ben olyan rounding, ami a hasznos digit-ek alapján kerekít a kimenet olvashatóságának javításáért. Mindenhol ilyet használok, csak más nyelveken. Mivel állandóan értékeket kell olvasni, ezért nem mindegy, hogy ránézésre mennyire gyors az értelmezés.

Ez Livescript kód, amit JS-re konvertálok.

round = ( x, ndigit = 3 ) ->
    n = Math.round( Math.log10( Math.abs( x )))
    n2 = ndigit - 1 - n
    n2 = 0  if n2 < 0
    res = parseInt( x * 10**n2 ) / 10**n2
    return res

Kimenetek:

0.00001234567 => 0.0000123

12.34567 => 12.3

12345.67 => 12345

Ha valakinek hasznos, akkor használjátok egészséggel.