Neuropočítač – Matematika – Fórum – Programujte.com

Ahoj, hraju si poslední dobou s umělými neuronovými sítěmi a vymyslel jsem si takový fajn algoritmus.

Co myslíte, mohlo by to k něčemu být?

Zatím to nemám popsané, mám jen program, přesné vysvětlení ještě dopíšu, ale ono to není složité.

Jde tam o to, že síť má sice jen jednu vrstvu (ty pak půjde skládat na sebe), ale neurony jsou propojené navzájem.

Výsledkem je, že síť se má chovat jako konečný automat (nebo i více nezávislých automatů).

Propojení mezi neurony v jedné vrstvě odpovídá tabulce přechodů mezi stavy automatu.

Vstupy přitom nejsou signály spojitě se měnící v čase, ale jednotlivé krátké pulzy.

Nesleduje se intenzita pulzů, ale pouze jejich časové návaznosti.

Ještě nemám úplně doladěné učení, ale vybavování již naučeného funguje docela dobře.

Vlastně to má vyhledávat posloupnosti pulzů a pro každou takovou posloupnost vybudit příslušný neuron.

Snaží se to vyhodnocovat, s jakou pravděpodobností mohla příslušná posloupnost pulzů přijít.

Co si o tom myslíte, mohlo by to k něčemu být?

Ale ono se jen v programu asi nikdo moc nevyzná, že jo?

Děkuju moc,

Petr

#1 Petr Šlechta
Ještě jsem zapomněl ten program.

Je tady: http://piitr.sweb.cz/neuro/neuro.c

#1 Petr Šlechta
Jelikož to nebylo úplně přehledné, program jsem zjednodušil

Je úplně dole na http://piitr.sweb.cz/index.html

Přidal jsem tam i výstup programu.

Posloupnost pěti vstupů to rozezná docela spolehlivě - výstup je asi 200x vyšší než normálně.

#3 Petr Šlechta
Trochu si ten program procházím. Na to, co to umí, se mi zdá příliš dlouhý. Možná, kdybys ho napsal objektově, byl by jistě kratší a mnohem srozumitelnější.

Spousta komentářů jen popisuje, co dělá algoritmus, ale chybí v nich, proč to dělá. Takové komentáře jsou zbytečné a pouze programu škodí.

Máš tam spoustu globálních proměnných a statických metod. Pokud se aplikace rozroste, stane se neudržovatelnou. Je tam také hromada duplicitního kódu, což je také velmi riskantní pro údržbu. Přepsáním do OOP tyto duplicity zmizí.

Zkouším ten program přepsat do Javy, ale to asi bude na delší dobu.

Souhlas, ze je to tam hlavne emulace objektu, v c++ by to bylo vyrazne prehlednejsi a daly by se pouzit kontejnery na data a tak (tim by se minimalizovaly chyby v tech seznamech a tak)

static double max(double a, double b)
{
	if ( a > b )
	{ /* a is greater, it is the maximum, return a */
		return a;
	}
	else
	{ /* b is greater or equal, it is the maximum, return b */
		return b;
	}
}

Jj, zbytecne popisky. Proc tady popisujes "doslovne" kod?

Proc tam mas "if-else" a ne "return podm ? a : b"
Taky je dobre u if-else rozvazit, ktera cas muze nastat casteji a tu davat jako prvni do if. Treba, kdyz vis, ze budes serazovat haldu nahodnych cisel, tak lze predpokladat, ze v prvni vlne budou vicemene nahodne a ve druhe uz je vetsi sance, ze prvni je mensi (zalezi na algoritmu).
Treba, kdyz hledas minimum cisla prochazenim pole, tak lze predpokladat, ze prvni cislo bude na zacatku nahodne vetsi mensi, ale ke konci jen mensi. Coz mas dobre v tom kodu. Minim to jen jako takovou poznamku.

Pro i++ rychlejsi je ++i, pokud nepotrebujes predchozi hodnotu. Napriklad funkce(i++), do funkce jde i. funkce(++i), po funkci je i = i+1, do funkce jde i+1.

random() % 100 / 10000.0 - random funkce se daji take urychlit, ted si ale nevybavim jak je to v c++

#6 peter
Nejvíc se ušetří, když se else nepoužívá vůbec...

static double max(double a, double b) {
    return (a > b) ? a : b;
}

vypadá nejen elegantně a čitelně, ale je to i efektivní.

Optimalizace, které nezlepšují čitelnost programu, jsou zpravidla zbytečné. Kompilátory obvykle optimalizují mnohem lépe než programátor - ten může efektivně optimalizovat pouze výběrem vhodného algoritmu.

#4 Kit
Omlouvám se za delší odmlku, mám teď toho moc. Jsem moc rád, že jste se na to koukli. Popis, proč se tam co dělá, jsem zkusil doplnit na http://piitr.sweb.cz dolů. Jsou tam nějaké výpočty, na lepší vysvětlení nemám teď čas, ale doufám, že se k němu dostanu. Ještě kolem toho mám hodně nedořešených věcí.

#6 peter
Jinak, k mému způsobu psaní.

Asi záleží na vkusu. Já jsem to objektově schválně nepsal. Mám to jako od lopaty, aby to bylo jednoduché. Ono to slouží k testování algoritmu. Pořád jsem to přepisoval. Já jsem to nejdřív objektově začal, v Javě, ale pak jsem toho nechal. Hlavně jsem si od toho sliboval lepší čitelnost, ale byla spíš horší.

Jinak, ten if - já používám radši if-else než ?:. Důvod je ten, že ke každé větvi můžu napsat komentář. Mně to pomáhá, když se pak k programu po čase vracím.

#9 Petr Šlechta
Musím se trochu opravit - já jsem to objektově začal, ale to bylo před lety a tenkrát jsem ještě používal úplně jiný algoritmus. Tenhle jsem objektově ani nepsal, ten už jsem psal rovnou v céčku. Takže přepsat to do Javy má z tohohle pohledu smysl. Akorát ten algoritmus je potřeba ještě dopilovat, takže to je možná trochu předčasná práce. Rozhodně se tím přepsáním do objektů získá to, že nebude muset být spojen každý neuron s každým. To je dost důležitá věc. To jo.

#9 Petr Šlechta
Objektově se píše proto, aby se zlepšila čitelnost programu. Pokud se ti ta čitelnost zhoršila, nepíšeš objektově.

K ternárnímu operátoru také můžeš psát komentáře, i když ke komentářům mám poměrně vyhraněný postoj. Většina z nich je totiž zcela zbytečná - jejich text obvykle patří do názvu proměnné.

#11 Kit
Asi se to těžko vysvětluje a možná je to i subjektivní, ale zkusím napsat svůj pohled. Vlastně máme asi pravdu oba. Kdyby ty programy měly dělat totéž, tak ten objektový bude přehlednější. Ale já jsem radši udělal jednoduchý program v céčku, který toho neumí tolik, ale ten algoritmus je v něm lépe vidět. Konkrétně jde hlavně o to, že nemám neurony jako objekty, které si můžu libovolně provazovat do složitějších struktur apod. To jsem v tom objektovém přístupu měl a je to docela potřeba. V tom céčku to není, tam je prostě spojený každý neuron s každým. Pro praktické použití je to obrovský handicap, ale ten algoritmus se mi na tom lépe zkouší a modifikuje.

S těmi komentáři je to složité. Vím, že jdu docela proti proudu. Já je radši píšu. Docela se mi to osvědčilo, ke každému větvení psát nějaké vysvětlení. Když se časem k programu vrátím, trochu to pomůže. A když nepomůže, lze komentář vylepšit. Když tam vůbec není, tak už tam nikdo nic dopisovat nebude. Když tam je, je alespoň nějaká šance. Ono se říká, že program se jednou píše a hodněkrát čte, tak se podle toho snažím řídit. Taky se pak dá za každé větvení dát logování a dobře se sleduje, kudy přesně program běžel. To už se mi docela vyplatilo, třeba při ladění programu s více vlákny. Ale jak říkám, vím, že v tomhle jdu dost proti proudu, tak nechci nikoho přemlouvat. Mně to prostě vyhovuje, tak to tak dělám.

To "Komentáře označují místa, kde programátor udělal chybu." je pěkné.

#12 Petr Šlechta
Ani v tom Céčku nemusíš mít každý neuron spojený s každým. Když si je rozmístíš např. do tří vrstev tak, že každý neuron bude mít vazby pouze na neurony sousední sítě, ušetříš velké množství výpočetního výkonu.

ad komentáře: Nejvíc se děsím zavádějících komentářů, jako je např:

for (i = 0; i <= 10; i++) { // akci provedu 10×
    akce();
}

Čtenář pak nečte zdroják, ale komentáře, což je v daném případě špatně. Pro programátora je to také zbytečná zátěž, protože pokud "10" vymění za "15", musí to měnit na dvou místech. Kromě toho by se taková konstanta v programu vyskytovat neměla, na to máme #define nebo const. Tím do programu vpašujeme i řádný komentář ve formě názvu konstanty.

Pokud je komentářů víc než zdrojáku, což je častý případ, je to pro čtenáře velkým zdržováním. Zejména pokud pouze popisují, co program dělá - to je přece patrné už ze zápisu algoritmu.

Místo komentářů raději používám testy. Jsou užitečnější.

#14 Kit
Až se to bude dělat vícevrstvé (ten můj program řeší jen jednu vrstvu, vrstvení bude trochu jinak než normálně), tak bych to asi už dělal spíš objektově. Nejlíp asi v té Javě. Ale v céčku by to šlo taky, to je pravda.

Ad komentáře: Vím, že můj přístup není úplně obvyklý. Nechci nikoho přesvědčovat, aby ho používal. Já to tak dělám, protože mi to vyhovuje. Testy jsou fajn.

#15 Petr Šlechta
V OOP se neurony dělají nejlépe tak, že každý z těch neuronů sázíš do vzoru Observer. Učení pak uděláš tak, že ho nejprve projdeš shora dolů, opravíš výstupy a následně  projdeš zdola nahoru. Opakuješ podle potřeby s různými kombinacemi vstupních a výstupních dat.

Každý z těch neuronů má v sobě další Observer se vstupy a jejich váhami. Tím vzniknou jen takové vazby, které potřebuješ - ušetříš tím na paměti i na výkonu.

Vzhledem k tomu, že nikde nepoužíváš indexy, ale jazyk interně využívá pouze ukazatele, je to i docela rychlé.

#16 Kit

Observer? Nezlob se, ale to mi nepřijde úplně ono. Za prvé, v tom učení to chce trochu dopilovat po matematické stránce (základ je podle mě dobře, ale má to mouchy, zatím se třeba všechny neurony učí totéž, chce to si s tím ještě chvíli hrát, ale já mám teď bohužel celkem horší problémy). Jak se přesně napíše ten for cyklus, to mi přijde celkem jako detail. A za druhé, ten observer mi přijde o něčem jiném - tam se na existující objekty registrují posluchači, kteří chtějí reagovat na jejich změny. Jenže ten neuron se má učit sám, váhy mu nemá měnit někdo zvenčí. Sám si je musí měnit. Observer by se mi zdál třeba vhodný ke sledování, že se vybudil výstup neuronu, a podle toho by se např. spustil motor nebo tak.