sinexton blogja

Vlog / törés detektálás adatban

https://youtu.be/KRSVgx1Dcn0

 

Néhány kiegészítés a videóhoz:

- nem kell szükségszerűen letörési limitet találnia az eljárásnak, hiszen pont ezért adaptív, hogy ő maga döntse el hogy van-e és hol az adatban

- bizonyos esetekben segíthet a hibatűrésben, ha azt mondjuk, hogy az ismert szennyeződés mértéke nem nagyobb mint 50% az adatban, mely esetben a letörési pontnak 50%-nál nagyobbnak kell lennie - ez teljesül is, ha kevesebb a munka művelet munkaidőn kívül

- nem minden adatnál jelent anomáliát a 3 szóráson kívül eső érték - itt olyan példát mutatok, amelynél annak tekinthető

Csoportosítás, hogyan és miért?

cluster

(kép infó: 2 dimenziós cluster vizuálisan csoportosítva, ahol a szürkék a nem csoportosított zajt vagy túl kicsi halmazokat mutatják)

 

Bármilyen matematikai eljáráshoz nyúlok vagy újat tervezek, mindig végül köze lesz a log-hoz vagy exponenciálishoz. Nagyon érdekes számomra az univerzum ezen karakterisztikája. Amint átlép a folyamat additív domainből multiplikatívba, tele lesz a megoldás exp és inverz exp-el.

Terveztem egy új clustering típusú gépi tanuló eljárást, mely kedvezőbb tulajdonságokkal bír számomra az ipari és akadémiai területen elérhetőkhöz képest. Kezdjük ott hogy miért?

A matematikai eljárások tervezői előszeretettel tolják vissza az egyik legnehezebb problémát az algoritmusuk felhasználóira. Nekik ez az egyszerű. Ugyanis azt mondják, hogy ha ezt és ezt a paramétert megadod, akkor tuti jó eredményt adunk. Tehát parametrikus. Ezért jó paraméterek nélkül nincs használható eredmény. Akkor már csak a paraméterek kellek. Jön a következő kérdés: Hogyan találja ki a user az optimális paramétereket? Például k-means vagy k-nearest algo esetén mekkora legyen k értéke? Az egyszerű válasz: sehogy.

Ractor

Real and native parallelism for Ruby 3.x

https://ruby-doc.org/core/Ractor.html

require "etc"

# get number of cpu cores and run as many cycles
p Etc.nprocessors.times.map {
	# run separate real thread
	Ractor.new {
		# do time consuming operations
		10_000_000.times.map {
			rand
		# sum up result
		}.sum
	}
# wait for all threads and get results and sum them up
}.map(&:take).sum

Output:

60001925.166772075

Feléből a gyökét

Megosztok egy fantasztikusan leegyszerűsített számítást, mely annál szofisztikáltabb elméletből származik és mely elég hasznos. Úgy látom, hogy nem sokan ismerik és használják. Például marketinghez hasznos lehet, melyet bizonyára sokan használnak valamilyen formában.

Mi a téma?

Arányok vizsgálata. Angolul proportion test.

Mi a cél?

Arra választ kapni, hogy 2 érték aránya között van-e akkora különbség, hogy statisztikai bizonyítéknak tekinthessük a különbséget és így segítsen minket egy megalapozottabb döntésben.

Példa:

Megfuttattok 2 fajta marketing kampányt. Például máshogy fogalmaztok benne. Egyik puha, másik rámenős.

Telefon pontozás matematikailag

Sziasztok, ha valakinek időt spórol és segítek vele, akkor használjátok a listám egészséggel. Leprogramoztam a forgalmazók PDF-jeiből a telefon név és ár kiparsolását, majd ezek alapján a GSMArena oldalról a speckók behúzását, majd pontozását. Manuálisan rengeteg munka lenne.

https://www.facebook.com/andras.horvath.940098/posts/2133101146865603