sinexton blogja

Nem elektromos, alsó kategóriás gépjárművekre vagyok kíváncsi. Felül vannak a jobb választások. Kék és piros oszlopokat használom a pontozáshoz, ahol kék a pozitív tulajdonság (több a jobb), piros pedig a negatív.

Ha valakinek van kedve és segítene felvinni még több márkát és típust, az talán nem csak nekem segítene a választék kutatásában. A pontozáshoz szükség van mindegyik pontozott tulajdonságra.

https://docs.google.com/spreadsheets/d/1lpjTfqYKjvClMTAA5LuqBgxXHkcdrH_…

Sajnos az árak jócskán nőttek az elmúlt 2 évben. Viszont a kereskedők ár szórását és a termékek paramétereinek szórását kihasználva lehet optimálisabban dönteni.

Mekkora cégünk pénzügyi hatékonysága? Több módon mérhetjük. Ha viszont arra akarunk választ kapni, hogy a most lezárult időszakban mennyire voltunk hatékonyak, akkor ezt egy másik időszakhoz kell viszonyítanunk.

Kiteszem blogba egy válaszom:

https://hup.hu/comment/2801903#comment-2801903

További limitációkat bontok le az adaptív döntésnél.

https://youtu.be/MLSYaEel_V8

https://www.geogebra.org/graphing/ubzeq8bv

Részletek lejjebb.

Monitort keresek. Megnéztem a győri BitBolt mai árlistáját. Eredmény itt.

Ha automatizáltok felhős erőforrásokat és megnövekedett igény esetén bekapcsoljátok, akkor azt is le kell programoznotok, hogy mikor kapcsoljátok le, ha vissza csökken az igény.

Nem triviális a kérdés. Az optimum keresés szükségességét az adja, hogy tudjuk, van egy még nem jó, és egy már nem jó határ. De vajon hol van közte a jobb döntés? Tudjuk-e közelíteni? Érdemes-e?

Ha egy webes vagy helyi infra szolgáltatás régebb óta üzemel, akkor az azt kiszolgáló szerver háttér jó eséllyel vagy alul van tervezve, vagy pedig felül. Kérdés hogy melyik és mennyire? 2 fajta megközelítést használhatunk ennek elemzésére.

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ő

https://youtu.be/d9szcVOw-Bc

https://youtu.be/MMWG9oGZZ8Y

def adaptive_order( list, keep = 0 )
	temp = {}
	list.each_with_index{|x,i|
		temp[x] = temp[x].to_f + 1.0 / ( list.size - i + 1 )
	}
	res = temp.sort_by{|k,v| v }.map{|k,v| k }
	keep2 = ( keep > 0 ? list.reverse.uniq.first(keep) : [] )
	res = res - keep2 + keep2.reverse
	return res
end

Auditnál vagy forgalmazott termékek ellenőrzésénél, illetve egyéb területen hasznos lehet ismernünk hibakereséshez a minimum elvégzendő lépések számát:

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

(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.

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

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.

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