Genetikus programozás java nyelven (szabadidős tevékenység )

 ( znurgl_ | 2006. május 27., szombat - 18:52 )

Sziasztok!
Jobban meg szeretnénk ismerni a genetikus programozást (tierra,algoritmusok tenyésztése), ehhez keresünk javaban jártas embereket. Nem vagyunk MI profik, csak érdekel a téma.
üdv,
znurgl tekercs gmail krumpli hu

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Konkret kereskedelmi/kutatasi celra, vagy csak hobbibol erdekel a tema? :-)

PS: IMHO, java nem biztos, hogy egy szerencses valasztas lesz

---------------------
Ригидус а бетегадьбол

Meg szeretnénk tanulni, hogy később kutathassunk, és kerekedelmi célokra használjuk ;-) (vagyis én, a többiek nem tudom)
Java: igen, ezen sokat töprengtünk, hogy milyen nyelven. Viszont a javahoz van lisp kiegészítés, ha nagyon nem menne, de ez csak a gyakorlatban fog úgyis kiderülni.
Természetesen tanácsokat itt is nagyon szívesen látunk.

znurgl

email ment... :-)
---------------------
Ригидус а бетегадьбол

Bár nem tudom, hogy Neked írtam-e e-mailt ez ügyben, de a kutatáshoz szívesen csatlakozok. Csak tisztázzátok az ott felvetett kérdéseimet ;)

Szerintem erre a Java a legszerencsésebb választás.

Egyrészt tudnak futásidőben osztályokat összerakni, másrészt ha forráskód-módosításokban gondolkodnak, akkor a groovy és hasonló eszközökkel nagyon kényelmes eszközöket kapnak. Bátran mutálhatják a kódot, ugyanakkor hozzáférnek Java objektumokhoz...

Egyéb, MI-ben divatos nyelvekkel biztosan nem állnék neki. Azokkal már 40 éve próbálkoznak nagyon okos emberek, mégsem jutottak eredményre :)

Hat igen, ez is egy szempont. :-)

---------------------
Ригидус а бетегадьбол

Tán nem véletlen próbálkoznak azokkal a nyelvekkel a nagyon okosok...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

LOL

---------------------
Ригидус а бетегадьбол

Bizonyára az átütő eredmények véletlen maradtak csak el :)

Azt hiszem ez egy kicsit hitvita, nyugodtan kijelenthetjük, hogy mindenki használjon olyan eszközt, ami számára megkönnyíti egy adott feladat elérését :)

Az átütő eredmények valószinű azért maradtak el, mert kicsit kevés a számítási teljesítmény, illetve nem megfelelő a modell.

Tekintve hogy az egyszerű nyelvek is Turing teljesek, nincs olyan algoritmus amit ne lehetne velük megoldani.

Azért használlják pl a LISP-et az okosok, mert lényegesen egyszerűbb a kifejezésfát felépíteni a forrásból, azt mutálni, keresztetni, majd forrást generállni.

Nyilván java-ban is megoldható, csak 10x annyi idő...

Persze mindenki azzal b@ssza el a szabad- (és nem szabad-) idejét, amivel akarja.

Csak gondoltam, hogy ha már meg akarod váltani a világot, legalább ne ilyen naivan próbáld.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Persze, nyilvánvaló amit írsz. Ahogyan az is nyilvánvaló, hogy assemblyben is meg lehet írni minden algoritmust. :) A jelenlegi helyzet a tudományos nagyvilágban az, hogy általában (tisztelet a kivételnek) a legtöbb eszköz ismeretében olyan 3-10 éves lemaradásban vannak, és aki nem ismer más eszközt, nyilván azt használja, amit ismer. Sokan még mindig abban a tévhitben élnek, hogy a Java lassú, esetleg csak Java szintaktikával lehet rá fejleszteni (http://groovy.codehaus.org/), hogy csak néhány példát említsek.

Persze mindenki azzal szúrja el az idejét, amivel akarja, de a LISP-es kifejezés-fáknak is megvan a maguk limitációja, amely miatt nyilván csak egy adott feladatkörig tudod használni. Ha valaki most kezd el a témával foglalkozni, akkor érdemes végignézni az alternatív lehetőségeket (Lisp, Ocaml, Prolog, SML, ...), de szerinte hosszabb távon megtérül az általános nyelvel történő fejlesztés. A célszerszámoknak megvan az az előnye, hogy egy adott feladatra tökéletes kalapácsot adnak, de ha más nyelvvel közelíted meg a feladatot, akkor egészen más aspektusból láthatod. Jó példa a Prolog vs hagyományos program: Prologban megfogalmazhatod egy sorban is a bonyolult kifejezésedet, de ha nem a prolog mélységi bejárásával oldottad volna meg az adott problémát, lehet hogy nem 1 hét, hanem 1 óra alatt lefutna.

Én pl. az elmúlt rövidebb időszakban éppen gráf-kutatással foglalkoztam, amihez valószínűleg soha nem használnék más nyelvet, mivel pl. Javaban kényelmesen meg tudtam oldani, hogy elfedtem a gráf konkrét tárolási helyét (memória / adatbázis), az algoritmusaim átlátszó módon kezelték. Ezt mondjuk prologba nehezen teszem meg, és ilyen apróságon pl. az múlhat, hogy egy nagyságrenddel nagyobb gráfot is tudok kezelni, nem kell a NIIF-es szuperszámítógéphez accountot kérnem. (Bár de, a számítási komplexitás miatt nem jönne rosszul :) ).

Elismerem, hogy kicsit lekicsinylően írtam más eszközökről, ezért elnézést kérek, de amit írtam, annak megvan a saját tapasztalati háttere. Más emberek háttere ettől bőven eltérhet, nyilván ők is megírhatják a tapasztalataikat, ha kisebbségben leszek, akkor egyértelmű, hogy nincs igazam.

Na látod, én biztos nem álltam volna neki egy számításigényes feladatnak Java-ban...

Mert a Java egyrészt lassú, másrészt zabálja a memóriát. Ez a megállapítás igaz a programok többségére (és itt most nem a szintetikus benchmark-okra gondolok).
Hogy ez a nyelv, a futtatókörnyezet, vagy a programfejlesztők hibája, az nyilván megérne egy vitát, de tény.

És abban is igazad van, hogy minden nyelv másra jó, és akkor járunk el értelmesen, ha azt választjuk amihez ki lett fejlesztve.

Pl nem mindegy, hogy Prologban 1 napos munkával beírod a kifejezéseket, és utána 1 nap alatt lefut (hozzátenném, hogy a Prolog (legalábbis a SICStus) marha gyors), vagy fejlesztesz 2 hétig mondjuk C-ben, miközben szinte újraírod a Prolog felét, és utána megkapod a megoldást fél nap alatt...
Lisp-nek pont az a lényege, sőt talán ezért is találták ki, hogy könnyen feldolgozható legyen.
Pont ezért a Lisp-et ajánlanám a kezdőknek, hogy kevesebb munkával megoldjanak egyszerűbb feladatokat, és csak ez után mélyedjenek el valami komolyabb problémában.

"Sokan még mindig abban a tévhitben élnek, ... csak Java szintaktikával lehet rá fejleszteni"
Azért ez csúsztatás. A Java egy nyelv. Olyan nincs, hogy nem java szintaktikával fejlesztek java programot.
Olyan van, hogy létezik java-bytecode fordító más nyelvre.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Most, hogy teljesen felhergeltetek, meg is nézem magamnak a Lisp-et :-)
A LISP programozási nyelv / Zimányi Magdolna, Kálmán László, Fadgyas Tibor
Budapest : Műszaki Könyvkiadó, 1989

Kérdés: ennek mennyi haszna van a mai világban? Ha valahol alkalmazni kell MI megoldásokat, biztos, hogy a lispet, prologot fogják számon kérni az embertől?

Ha tudtok konkrét példát, annak is örülnék.

"Ha valahol alkalmazni kell MI megoldásokat, biztos, hogy a lispet, prologot fogják számon kérni az embertől?"
Hat eleg valoszinu, hogy ezek ismerete nelkul szoba sem allnak veled.

Nem reklam, de ha tenyleg erdekel a LISP, akkor ajanlom Paul Graham bacsi LISP bibliajat. Nem olcso, de IMHO ebben megtalalsz mindent ami neked kellhet.

---------------------
Ригидус а бетегадьбол

Imádom, amikor nagy hévvel azt mondják, hogy a Java lassú. Kérlek nézd meg a következő linket:

http://www.bytonic.de/html/benchmarks.html

Segítek: ez egy Java-ban implementált 3D játék. A link konkrétan a benchmark eredményekre mutat. Ha hiszed, ha nem: nem lassú. De előjövök egy másik linkkel:

http://freetts.sourceforge.net/docs/index.php#performance

Ez egy beszédszintetizátor. Elég számításigényes feladat, nem? Bizonyára véletlen, hogy a feldolgozási időben jobb teljesítményt mutatott, mint ugyanazon program régi C-s változata.

És ezen kívül számos, szintetikusnak bélyegzett tesztet tudok mutatni illetve én magam is kimértem, hogy a Java nem lassú. Hagyjuk már az óvodában ezt a "Java lassú" mondókát...

De nézzük tovább: a Java nem csak egy nyelv, hanem egy futtatókörnyezet, egy platform. Ha vetted volna kicsit is a fáradtságot, és megnézted volna a hivatkozott linket, akkor láthatod, hogy az egy nem-java szintaktikával, mégis JVM alatt futó környezet.

De akkor sorolom még, hogy többek között mi mindennel tudsz Java Virtuális Gép alá fejleszteni:

Ruby: http://jruby.sourceforge.net/
Python: http://www.jython.org/
PHP: http://www.caucho.com/resin-3.0/php/index.xtp

Persze mindenre rá lehet fogni, hogy csak fordítás, de akkor mi nem fordítás? :)

Ó, és majd kihagytam:

LISP: http://jatha.sourceforge.net/

Magyarázat a felháborodásomra: egyik hallgatóm TDK munkáját azért bírálták le, mert Java-ban implementálta a feladatát, és a bíráló és az elnökség meg volt róla győződve, hogy a Java lassú. Azóta nem szeretem azt, amikor valaki bután mormolja az imamalmot. Egy másik hallgatómmal mértünk néhány tesztet, az ide tartozó kódok és eredmények elérhetőek innen:

http://sourceforge.net/project/showfiles.php?group_id=160620

A hivatkozott cikkben van még link néhány másik teljesítmény-mérésre, de pl. a veszprémi egyetemen is mértek Grid rendszer összehasonlító teszteket, nem csak szintetikusan, hanem konkrét alkalmazásokra. Mindenhol az jön ki, hogy a Java -5% - 20% sebességkülönbséggel fut átlagosan. Igen, -5%, azaz van, amikor gyorsabb (rekurziók kezelése, futás idejű optimalizáció). Mindez természetesen C++-hoz hasonlítva

Mint az talán az aláírásomon is látszik, nekem nem kell magyarázni, hogy a c++-ban könnyű nagyon lassú programot írni :)

Na jó unom a vitát, zárjuk rövidre:
Én nem szeretem a Java-t (talán ez kiederült), rengeteg rossz tapasztalat miatt.

Legnagyobb gondom, hogy nem arra használlják amire ki lett találva.
Pl Gridben ideális lehet, elvégre nem kell a progit 23 fajta arch-ra lefordítani.
Vagy pl webes felhasználásra, hogy ne kelljen a banki beléptetőrendszert, vagy bármilyen clienst megintcsak 200-szor megírni.

Viszont idióta dolognak tartom pl webservice-okhoz, vagy webservernek. Egyetlen előnye a hatalmas lib gyűjtemény, de ezt bármi más nyelvhez is megírhatták volna.
Biztos nekem nem volt szerencsém, de jsp-s weblapok nekem mindig nagyon lassúnak tűntek...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Én PHP-t és javat hasonlítottam össze webserver kiszolgálásnál.
Ég és föld a különbség.
A java veszett gyors a php-hoz képest :-)

Köszönöm a kioktatást... :)

A belinkelt Java játék érdekes választás, mivel OpenGL-t használ, így nem a legjobb viszonyítási alap, mivel nehezen kideríthető, hogy a processzoridőből mi mennyit használt.

Egyébként a teszteredmények sem egyértelműek, mivel a 4 tesztből csak az első három a számít, ezekből meg csak egynél jobb a Java, ott sem szignifikáns a külömbség.

De tegyük fel, hogy elfogadom, hogy nem lassú. Még mindig ottvan a memoria problémája...

Pont erről van szó, ahogy te is írod: JVM a futtatókörnyezet. Java egy nyelv.

Mint te is írod: "De akkor sorolom még, hogy többek között mi mindennel tudsz Java Virtuális Gép alá fejleszteni"

Mintahogy többmindennel tudsz .NET-re fejleszteni. Ott a C# az egyik nyelv.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Jah, és ha opengl-t használ, akkor a többi része is gyors? :) Nem az a lényeg, hogy a Java mindennél gyorsabb, ezt nem állítja senki. De az, hogy lassú, az legfeljebb 15-20%-ot jelent C++-hoz képest, de általában 0-10% az eltérés.

Valahogy azt érzem, hogy egyszer használtál Java-t, akkor még talán lassabb volt, most meg fújsz rá, nem is akarsz tudni róla. Ez oké, csak legalább ismeretlenül ne szóld le. A JSP-k is sokat fejlődtek az idő során, megvannak annak is a megfelelő helye és szerepe.

És igen, nagyon nagy API van hozzá, ami miatt a JVM több memóriát eszik, mint egy primitív C program, naná, ahogy az elvárható ha ott van mindig mellette az API. De talán nem ez a lényege a C-hez képest? Konkrétan arra gondolok, hogy ott egy csomó, egyből használható osztálykönyvtár, ami nagyon-nagyon sok feladatot megold. Persze, meg lehetne írni bármilyen másik nyelvre, de erre már megírták, a Sun JVM (a BEA JRockit mellett) a legfejlettebb technológiát képviseli, egyszerűen nem értem, hogy miért kell leszólni, pláne ismeretlenül.

Ha megnézed az általam is jegyzett méréseket, akkor látható, hogy mire mentünk rá: ugyanazt a kódot implementáltuk Java-ban és C++-ban. Pl. mátrix-szorzást, vagy quicksortot. Lehet mondani rá, hogy mikrobenchmark, de akkor milyen benchmark kell? Ott a FreeTTS, az nem mikrobenchmark. Nem nagy a kérésem, csak annyi, hogy felejtsd el, hogy a Java lassú :)

Nem ertem miert nem lehet vegyes megoldast hasznalni,valamiben az egyik jobb valamiben a masik, miert nem lehet erre az egyiket arra a masikat hasznalni. Nekem most pont egy ilyen vegyes feladatom van, a program nagy resze java, de vannak prologban implementalt algoritmusok is. Javabol szepen lehet prologot kezelni, prologos fuggvenyeket hivni, es viszont.

Igen, ezért gondoltam, hogy talán nem akkora mellélövés a java.

Összefoglalva az eddigi történéseket:
-konkrét cél a téma mélyebb elsajátítása
-eszközök: java és uml
-amik hirtelen eszünkbe jutottak:
-8 királynő probléma
-gráfszínezés
-kereső algoritmus tenyésztés
-tierra (Erről Mérő László írt: virtuális számítógépben önmagukat reprodukálni tudó programok versengenek a szűkös erőforrásokért)

Ha már így szétesett a topik (várható volt):

Ha valaki ismeri a Lisp jelenlegi helyzetét, kérem, válaszoljon a következőre:
Milyen Lisp IDE-t érdemes használni?

talan az emacs, de majd kijavitanak ha nem

/* bocs az esetleges helyesirasi hidakert */

{egy hozzászólás kétszer... bocs}

Erdekesseg a soruceforge.net-rol:
Artificial Intelligence project (3126)
C nyelven: 650
C++ nyelven: 1094
Lisp nyelven: 114
Java nyelven: 1380

Genetic Algorithm project (1244)
C nyelven: 205
C++ nyelven: 272
Lisp nyelven: 12
Java nyelven: 341

kb 50-50 % mi ebben a fura, nem gáz az ha valaki tud c, c++ ul :)

--
A bus station is where a bus stops. A train station is where a train stops. On my desk, I have a work station

HOl látod azt, hogy "fura"? Én csak adatokat közöltem, amiben a C/C++ azért szerepel, nehogy megint veszekedés legyen. Igazából a javara és a lispre voltam kíváncsi. Érdekes még, hogy ahányszor rákerestem a kifejezésre, mindig más értéket adott ki... Általában növekedett, szóval az adatok nem reprezentatívak!