Megoldásom:
Ha egy Excel táblázatban az “A” oszlop tartalmazza a múltbeli költségeket egy adott dologra adott időnként (például nyomtató papír heti költségei), akkor az alábbi képlettel számolhatjuk ki azt a felső limitet, amelynél többet nem kell félre tennünk erre a célra ekkora időre tervezve:
= AVERAGE(A:A) + STDEV(A:A) * ( 3 + LN( SKEW(A:A) + 1 ))
Példa:
Heti nyomtató papír fogyás költsége így néz ki (leosztva ezerrel):
77 82 35 222 34 31 103 51 227 26
Nagyság szerint sorba rendezve:
26 31 34 35 51 77 82 103 222 227
Grafikusan:
Fenti számítás alapján 380 ezer forintot kell hetente elkülöníteni rá, hogy ne fogyjunk ki belőle. Itt a 380 egy olyan extrém felső érték, mely azért extrém, mert elég ritkán fordul elő. A számítás pedig arra ad választ, hogy mennyire ritka előfordulást tartsunk elegendően ritkának.
Hosszabb magyarázat:
Sokszor kell megállapítanom matematikai modelljeim tervezésénél, hogy mitől kezdve túl extrém egy érték egy adott számsorban. Habár relatíve sok megközelítés létezik "outlier detection" témakörben 1 dimenziós adathoz, mégsem elég jók. Ugyanis a jobb eljárások általában feltételeznek egy eloszlást - például normál - mely sokszor nem teljesül.
Vannak robusztus eljárások, melyek függetlenek az adatban lévő értékek nagyságának eloszlásától, így nincs szükség feltételezésre az alkalmazásukhoz. Viszont nem elég megbízhatóak, mert sokszor alul lőnek az értékhatárral.
Megjegyzés:
Az értékek eloszlása azt mutatja, hogy milyen nagyságú értékből mennyi fordul elő. Például normál eloszlásnál a kis értékekből kevés van, az átlagosakból sok és a nagyokból szintén kevés. Míg exponenciálisnál a kis értékekből nem kevés van, hanem sok. A nagyokból pedig szintén kevés.
Normál eloszlás görbéje (e^-(x^2*c)):
Exponenciális eloszlás görbéje (e^-(x*c)):
A normál eloszlás azért normál (más néven gauss), mert véletlen rezgések összege mindig normál eloszlást közelít. Ebből pedig sok van környezetünkben, ezért ezt nevezzük normálisnak. Véletlen értékek szorzata pedig exponenciálist ad.
Normál eloszlásra rengeteg példa van. Például az autó gumink kopásának mértéke egy vezetés alkalmával. Legtöbbször átlagos mértékben kopik és ritkán kevésbé és ritkán erősebben. Vagy normál még az emberek magassága. Vagy elektromos autók aksijának teljesítménye egyetlen töltés alkalmával. Ez mind sok véletlen hatás összegének eredője.
Előző blogomban kombináltam a normál és az exponenciális eloszlás határérték számítását a ferdeség változásának függvényében.
Ferdeséghez lásd:
https://en.wikipedia.org/wiki/Skewness
Egy normál eloszlású adat első centrális momentuma az adatok középértéke, mely az átlag. Második momentuma az adatok négyzetes középértéke, mely a variancia. Harmadik momentum pedig az adatok köbös középértéke, mely a ferdeség. Van még egy negyedik is, mely a csúcsosság (kurtosis), de arra nincs szükségem, mert a második momentum már felel érte kisebb hatvány mellett.
Régebb óta kutattam, hogy hogyan tudnám csak a normál eloszlásra vetítve meghatározni az extremitás határértékét. Mégpedig úgy, hogy ha a normál eloszlás csonka, vagyis a bal oldalának egy része hiányzik, akkor is jól működjön. Például ha csak a jobb oldala van meg, akkor az félnormál eloszlást ad. Ha még kevesebb része, akkor már közelítőleg átmegy exponenciálisba. Ekkor is jól kell működnie az eljárásnak.
Azzal, hogy a normál eloszlás számításán belül maradok, egy konzisztensebb megközelítést kapok.
Mi az újításom?
A normál eloszlás határértékénél alapból az első és második momentummal határozzuk meg a limitet. Viszont ahogy nő a ferdeség (harmadik momentum), úgy lő alá az eredmény. Ezért korrigálom a határérték számítást a harmadik momentum függvényében. Hogyan?
Alapesetben az átlag plusz a szórás háromszorosa adja az extrém limitet. Itt a 3-as szorzót szigmának hívjuk, mert a szórás jele a görög szigma. Ahogy viszont nő a ferdeség, úgy növelem a szigma értékét. Kvázi egy szigma korrekciót végzek. Mégpedig logaritmikusan. És azért így, mert a lineárisan növelt szigma exponenciálisan elrobbanó limitet ad. Ezért logaritmikusan húzom vissza, hogy így a limit növekedése váljon lineárissá.
A logaritmikus növekedést a ferdeség alapján úgy állítom be, hogy amikor a ferdeség értéke nulla, akkor legyen az értéke a megadott szigma. Esetünkben 3. Így a tökéletesen normál eloszlásnál normális határérték számítást adok. A nagyobb ferdeségű eloszlásnál pedig már korrigáltat.
Lásd az alábbi függvényt, ahol a piros eredeti log függvényt tolom el kékbe, melynél az X = 0 pontban 3-as értékre van szükségem. Ettől jobbra pedig logaritmikusan növekedőre.
https://www.geogebra.org/graphing/umedrh4m
Megjegyzés:
Régebben írtam róla, hogy miért 3 szigmát javaslok határértéknek. Ez a normál eloszlás szórásának többszöröséből jön, mely a görbe alatti területet fedi le adott mértékben és így valószínűség számításban segít. A 2 szigma 95.4% megbízhatóságot ad, a 3 szigma pedig 99.7%-ot. A kettő választás általában elegendően lefed minden igényt. Vagyis normál megbízhatósághoz 2 szigmát javaslok használni, erős megbízhatósághoz pedig 3-at.
Nézzünk egy példát:
Értékek: 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 3 3 4 4 4 5 6 9 12 26 78
Ferdeség: 4.63
Grafikusan:
Limit az új eljárással: 74.4
Tehát az utolsó érték már túl extrém, mellyel nem kell terveznünk.
Példa arra, amikor eltér a normál limit és az én megoldásom:
Értékek: 5 5 5 5 6 6 6 7 7 7 8 8 8 9 9 9 11 12 14 14 15 25 32 33 33 36 40 45 74 82
Ferdeség: 1.94
Limit régi: 79.1
Limit új: 101
Tehát a régi eljárás már extrémnek találná a legnagyobb értéket. Az új pedig nem. Az újat megerősíti az exponenciálisan számolt limit is a 2-es ferdeség miatt (exp eloszlás ferdesége 2 alapból, tehát stimmel), mely 111.2-t határoz meg limitnek. Tehát az sem találja extrémnek a legnagyobb értéket. Így a számításom univerzálisabb a normálhoz képest és továbbra is konzisztens az előző fejlesztésemmel.
- sinexton blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
> Univerzumunkban nincs nulla és 100 százalék.
Ha a 100 fős cigányzenekar minden tagja megjelent a próbán, akkor hány százalékuk jelent meg?
No rainbow, no sugar
- A hozzászóláshoz be kell jelentkezni
Soha nem lesz 100% a részvételük esélye. Az esély mindig a jövőre vonatkozik, nem a múltra. Betettem azt a szót, hogy "esély", így valóban egyértelműbb.
- A hozzászóláshoz be kell jelentkezni
Raktál egy kikötést ami kb a végtelen halmaz. Ott tényleg nincs. Csak a mi világunk többnyire megszámlálható és véges.
- A hozzászóláshoz be kell jelentkezni
Ezért az extrém értékek előfordulása sohasem nulla vagy 100%. Ezért számolnunk kell vele.
Azt mondd meg akkor, hogy a képrendezőbe építsek-e olyan feature-t, hogy sha256 collision esetén összehasonlítjuk a fénykép tartalmát, vagy sem. :)
Az újak kedvéért: innen. :)
- A hozzászóláshoz be kell jelentkezni
Gondolom arra utalsz a linkkel, hogy nincs olyan HASH algó, amely kisebb bitszámmal dolgozik mint az input és nulla az esélye az ütközésnek. Végülis SHA256-nál 10^-77 az esélye az ütközésnek, ezt megengedjük a gyakorlatban. Mivel nincs nulla százalék esély, ezért mindig meg kell határoznunk egy minimális határértéket a hibának. Kérdés az, hogy mennyi elfogadható és optimális a gyakorlati folyamatok szempontjából?
- A hozzászóláshoz be kell jelentkezni
mit rovidit a HASH, hogy igy, NAGYBETUVEL irod?
- A hozzászóláshoz be kell jelentkezni
informaciobiztonsag? matematika? hat akkor tippre:
Hardcore and soft hackers
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....
- A hozzászóláshoz be kell jelentkezni
Gondolom arra utalsz a linkkel...
Nem, a thread több minden miatt is meme-worthy, de ez pont nem releváns. :)
- A hozzászóláshoz be kell jelentkezni
https://hup.hu/comment/2852574#comment-2852574
Hunger kérdezte, hogy mekkora az esély az ütközésnek. Érdekes egyébként látni, hogy ezek akkora számok, hogy emberileg nem tudunk mit kezdeni vele.
Egyébként szerintem a hash algónál gyorsabb lehet a következő eljárás, egy feltétellel:
Ha egy fájl adott indexen lévő byte-jának elérése gyors, akkor VÉLETLEN pozíciókból való mintavételezésnél az egyezés esélye exponenciális sebességgel konvergál nullához. Lásd ezt a blogom: https://hup.hu/node/177667
Tehát "pár" lépés elég. Ezért az újonnan megjelenő fájlok hash-el való végig nyalása nem szükséges. Illetve nem kell mod time alapján hash lista update sem.
Worst case scenario, ha sok nagy mértékben egyező fájl van. Ez esetben nem jó eljárás.
- A hozzászóláshoz be kell jelentkezni
Most olvasom ezt a részt :)
Hát igen, sokan nem gondolkodnak azzal, hogy nincs nulla és 100% esély, tehát ahogy Hunger is írja, a memória hiba esélye sem nulla. Tehát azzal is számolni kell. Sőt, a teljes fájl CMP esélye sem 100% hogy jól hasonlítja össze, mert akár kozmikus sugárzás is átbillenthet egy bitet.
- A hozzászóláshoz be kell jelentkezni