Ki, mit alkotott?
2010-01-26T06:02:05+01:00
2010-01-28T21:00:55+01:00
2022-06-30T17:41:00+02:00
  • Jelenleg azon gondolkodom, hogyan lehet GA-val vagy Cross Entropy Methoddal C# 4.0 Expression blokkokat növeszteni. Az az újítás a C# 4.0 Expression API-ban, hogy mostantól minden C# nyelvi elem támogatott, egy egész metódust fel lehet írni Expression API-val (CodeDOM++). Az Expression meg egy tree szerkezet. A fent említett algokat irányíott gráfokra már megvalósítottam hatékonyra, így tudok logikai áramköröket fejleszteni és optimalizálni csak az igazságtábla alapján. Most azt akarom elérni, hogy a faszerkezetet is támogassa a rendszer, így C# metódusokat is tudnék "növeszteni" - úgy, hogy csak a Unit teszteket kell megadni, a megfelelő mest. int. algo kitalálja azt a metódust, ami azokon átmegy.
    Mutasd a teljes hozzászólást!
  • Mért nem NN tréningel állítod elő a leghatékonyabb algoritmust?
    Mutasd a teljes hozzászólást!
  • Egyébként, ha mást nem, akkor egy dolgot megtanultam ezzel a projekttel. Bármibe is fog az ember, mindig a legegyszerűbbnek tűnő megoldással kell kezdeni. Durván két éve kísérletezem a legkülönfélébb globális optimalizációkon alapuló NN tréning algókkal, a fél Springerlinket letöltöttem, de én is vagy ezer saját módszer próbáltam ki. Tudjátok aztán mi lett a leghatékonyabb?

    private void Begin() { SaveWeights(); GenerateWeights(); TestNewWeights(() => { if (CurrentMSE > lastMSE || (CurrentMSE == lastMSE && RandomGenerator.FiftyPercentChance) || CanAccept()) { RestoreWeights(); } Begin(); }); }

    Ennyi. Mentem a súlyokat, generálok egy a jelenlegitől a hiba mértéke * egy vezérlőkonstansnyival eltérő értékű súlyokat, ha jobb, akkor elfogadom, ha rosszabb, akkor egy szintén a hiba mértékétől függő esély bekövetkeztekor fogadom el: RND() < (1 - hiba) * controlValue. Neszebumm. Messze gyorsabban konvergál, mint a minden eddig tesztelt algo. Ez majdnem egy Adaptive S.A., csak nincs benne matek, annál is egyszerűbb.
    Mutasd a teljes hozzászólást!
  • Az én nünükémről már beszámoltam egy másik topikban, de a blogomon olvasható, hogy miről fog szólni.

    Jelenleg alaig van heti pár órám, hogy bütyköljek rajta, de ha időm engedi, akkor a recurrent neuronhálózatok lehetőségeivel foglalkozom mostanában.

    Ha majd kész lesz, akkor ez nem egy classlib formájában fog megjelenni, mert ilyesmiből Dunát lehetne rekeszteni, hanem egy teljes WF 4 alapú mest. int. alakalmazásfejlesztési csomag készül belőle.

    Ezt nem ilyen mórickás tréninganyagokhoz és mikrohálózatokhoz találtam ki desktop körülményekhez, pl most fut egy arcfelismerő recurrent NN tréning a szerveren (IIS 7 hostolt szolgáltatásból!), minek az adatbázisa kerek 2 GByte (ezt a netről kukáztam össze az elmúlt években).
    Mutasd a teljes hozzászólást!
  • Hali!

    Tekintettel arra, hogy netangel "fegyelmez" minket


    Semmi probléma, nyugodtan értekezzetek a témáról (hisz' ez a Társalgó lényege). Én csak azért szóltam, hogy ne menjen el a téma
    egyik nyelv/eszköz vs. másik nyelv/eszköz
    irányba.

    Mutasd a teljes hozzászólást!
  • Kérek szépen mindenkit, hogy a kérdéseknek, és a válaszoknak inkább témát nyitni, mielőtt átmegyünk kérdezz-felelek-be...
    Példát lehetne venni a Hobbielektronika.hu::Ki, mit épített (Itt) topikjáról (mellesleg én innen vettem az ötletet, és ez nem reklám...)
    Valamint, szerintem nem baj az, hogy nem 100%-osan saját munka amit bemutatsz, mert az a lényeg, hogy részt vettél benne (persze mielőtt megosztod illik megkérdezni a társaidat, de ez mellékes)...
    Amúgy én is alkottam, egy Digitális órát java-ban, de az oldal, még nem végleges: Freeweb - Tárhely mindenkinek
    majd lövök még valahonnan olyan oldalt, ami támogatja a .jar-ba becsomagolt osztályokat, mert vagy én rontottam el, vagy az oldal nem támogatja, de nem akarja a képeket betölteni... :)
    Üdv.:Laci!
    Mutasd a teljes hozzászólást!
  • Annak idején egy csávó csak diplomapunkának írt egy bemutatóprogit az új 386 proci védett módjának használatáról.
    Jól kinőtte megát.

    akinek nem esett le, Linus Tordvald a csávó.

    Én régebben Delphiztem, próbálkoztam a Kylix-el, majd FreePascal / Lazarus kombóval, majd PHP MySQL.

    Perlben írtam egy Unix-Qoffice -> html konvertert, amit a cégnél használok.

    PIC-re írtam néhány érzékelés-vezérlés feladatmegoldást.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Tekintettel arra, hogy netangel "fegyelmez" minket, így nem fogok mindenkinek részletesen válaszolni, mivel az már tényleg nagyon OFF lenne. Azt a kicsit hosszúra sikeredett hozzászólásomat csak azért írtam le, mert a topiknyitó arra volt kíváncsi, hogy ki mit alkotott, és bár ez nekem még csak elkészülőben lévő projektem, mégis saját munkám, amit a téma megválaszolásaként osztottam meg veletek és a témynyitóval.

    Vagyis kérek mindenkit, hogy akit konkrétan az én projektem érdekel (akár csak elbeszélgetési céllal), az inkább küldjön privát üzit, vagy írjon a mail címemre:

    banderasz [at] gmail [dot] com

    Egyszer majd ha elkészül a fordítóm az eddigi saját specifikációim alapján, akkor majd nyitni fogok egy új társalgó topikot, amiben részletesen megbeszélhetjük majd akár a fordító tovább fejlesztését, illetve a projektem további (elvileg többrésztvevős) munkálatait. Ugyanott fogom a specifikációimat elérhetővé is tenni, és ugyanott fogadok majd javaslatokat, ötleteket is. Addig viszont kérek mindenkit, hogy -e projektemet hanyagoljuk itt a Prog.Hu-n, és csak PM-ben meg e-mail-ben írjatok nekem, ha érdekel titeket a téma.

    Köszönettel:
    Banderasz
    Mutasd a teljes hozzászólást!
  • Kiemelnék néhány "ficsőrt"/érvet, hogy miért jó ez így:


    Amikor az érveket olvastam, egyből a Google Web Toolkit ugrott be: az általad felsorolt érvek mind igazak erre a projektre is.

    A Google Web Toolkit végülis arról szól, hogy írsz egy alkalmazást Java-ban, mintha csak egy desktop alkalmazás lenne, majd abból egy trükkös Java to Javascript fordító segítségével automatikusan generálódik egy böngészőfüggetlen ajaxos kód.

    Nem azért írom, hogy hagyd abba a projektet, csak azért, hogy ötletet meríthess belőle.

    Nekem több témában is vannak dédelgetett hobbyprojekt ötleteim, néhány kislélegzetűt meg is valósítottam már. (Csocsó játék, szótanuló.) Fejlesztőknek szóló fejlesztés témában én egy real-time collaborative text editor (illetve IDE) illetve real-time verziókövető rendszeren szoktam fantáziálni. (Igazából az elképzelésem szerint ez annyira real-time lenne, hogy az editor és a verziókövető olyan szorosan integrálva lenne, hogy a klasszikus értelemben megkülönböztethetetleek lennének egymástól. Tehát az azonos branchen lévő fejlesztők látnák egymás kurzorját különféle színekkel, az égegyadtavilágon minden trackelve lenne (pl., hogy melyik sort ki módosította utokljára és mikor, sőt, ha a kód copypésztelve volt, akkor honnan volt copypésztelve. File átnevezések, refactoring követése alap:)), minden undozható lenne egészen a projekt legelső pillanatáig.) Egyszer majd még megvalósítom! (mint minden ötletemet)
    Mutasd a teljes hozzászólást!
  • Okés, bocsánat. Csak próbáltam kiindulásként néhány segédanyagot összeszedni az elinduláshoz. Jogos, ez a téma nem erről szól, de hősünk garázs-projektje beindította a fantáziámat.
    Mutasd a teljes hozzászólást!
  • ilyen Pascalos kodszeruseget lehetet bele irni


    Írjál Compilert, vagy legalább is egy assemblert...
    Mutasd a teljes hozzászólást!
  • Hali!

    Tisztelettel kérek mindenkit, nem menjünk el már megint "abba" az irányba...

    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Jut eszembe, a RemObjects, akik a Delphi Prism-et is csinálják, kiadtak egy teljesen ingyenes Object Pascal script motort forrással együtt. Innen letölthető: Pascal Script.
    Mutasd a teljes hozzászólást!
  • Ilyen alapon van Delphi for PHP is. Ezért nem is értettem, hogy miért jó az, ha nem binárisokat generál, hanem webes scripteket egy compilerrel.
    Mutasd a teljes hozzászólást!
  • Valahol el kell kezdeni:
    Entropy Overload: Writing a compiler

    Indított egy sorozatot is erről ott, mondjuk pont C#-al kapcsolatban.
    Mutasd a teljes hozzászólást!
  • Pont akartam írni, hogy emléxem, már a Delphi/Builder 6-oshoz is adtak valami ilyesmit.

    Én is szórakoztam pulya koromban saját nyelv és fordító gyártásával, BOOL lett volna a neve (Basic Object Oriented Language). Még mindig megvan a specifikáció, meg egy félig kész fordító (a legutolsó verzió már MSIL-re fordított). Eredetileg BCB6-tal kezdtem, saját IL + interpreter felett, de aztán jött a .NET, és megpróbáltam portolni arra. Azért akadt meg a dolog, mert kb. semmi értelme sem lett volna befejezni, rajtam kívül a kiskutya nem használta volna semmire, egyedül meg nem tudtam volna akkora promót csapni, hogy valaki elő is vegye - már ha egyszer befejezem.

    Ezt az ember kinövi, de gyakorlatnak nagyon-nagyon jó! Egy f4sz4 parsert írni egy összetettebb nyelvhez már igen húzós feladat, nagyon sokat lehet belőle tanulni.
    Mutasd a teljes hozzászólást!
  • intraweb
    Ez nemjó?

    Mutasd a teljes hozzászólást!
  • Nem lesz ez sok egy kicsit egyetlen embernek??? Egyébként ha Pascal compilert-t szeretnél készíteni, akkor érdemes jónéhány szempontot figyelembe venni, amire nem gondoltak anno pl. a Delphi fejlesztése során. Ezeket mindet Barry Kelly (Delphi compiler architekt) megosztja a saját blogján: Entropy Overload. Egyébként nem lenne rossz átbeszélni az egyes nyelvi elemek megvalósítást a nagyközönséggel, mert rengeteg buktatója van egyetlen "helytenül" implementált feature-nek is, lásd pl. Win32 generikusok. Például:

    A C# és a Delphi Prism a where kulcsszót használja generikus megszorítások meghatározására, míg a Delphi Win32 a megszorításokat közvetlen a típusparaméter mellett definiálja. 2 probléma is van emiatt:

    1. Nem tudsz használni rekurzív generikus paramétereket. Lásd: "Curiously recurring template pattern".

    C#: class BaseFactory<T> where T : BaseFactory<T>... Delphi Prism: BaseFactory<T> = class where T : BaseFactory<T>... Delphi Win32: TBaseFactory<T: TBaseFactory<T>> = class...

    Ez utóbbi (Win32) nem fog fordulni.

    2. Te nem tudsz kölcsönös megszorításokat tenni a paraméterekre, csak ha megfordítod a típusparamétereket:

    TMyClass<TA, TB: TA> = class end; // Ez jó.
    TMyClass<TA: TB, TB> = class end; // Ez nem, mivel TB még ismeretlen.

    Vagy pl. itt a kommentek között is olvashatsz néhány okosságot
    barry kelly kommentjeiből:

    http://www.deltics.co.nz/blog/?p=244

    Ott pont az automatikus típuskövetkezetésről és a lambdákról van szó. A kedvencem ez:

    It&#8217;s this parsing logic that the Delphi compiler isn&#8217;t designed to support. It was written with the assumption that it knew the types of every element upon parsing them.
    Mutasd a teljes hozzászólást!
  • Ilyen kérdésre (ha jól gondolom) nem illik olyan példákkal válaszolni, amelyek nem 100%-ig egyedi fejlesztések, mivel csapatmunkában mindenki érdeme a kész termék, nemcsak azé, aki itt írja. Így én sem mondok olanokat, amiket többed-magammal csináltam.

    Teljesen saját munkám alig van, mivel szinte mindig csapatjátékos voltam. De azért van egykettő említésre méltó alkotásom. Ezek közül csak egyet emelnék ki (pont olyat, ami még nincs kész).

    Az érem egyik oldala:
    Évek óta hanyatlik a Delphi, egyre kevesebben használják, pedig a mai napig nagyon sokan vannak, akik szívesen igénybe vennék, mert még mindig nagyon sokan értenek hozzá. Bár sokan vannak, akik ellenzik az ObjectPascal nyelv használatát, de talán mégtöbben vannak azok, akik szívesen használnák.

    Az érem másik oldala:
    Valljuk be őszintén, hogy az utolsó 10 év a webről, mint platformról szól. A web fejlődése (vagy inkább népszerűsége) az idő előrehalattával nem lineárisan, hanem exponenciálisan erősödik, amely tényt ma már nem szabad figyelmen kívül hagyni. Ráadásul egyre inkább a desktop alkalmazásoktól átveszi az uralmat a webalkalazások fejlesztése azon egyszerű oknál fogva, hogy nem lehet ellopni (nincs warez).

    A projektem (a készülő érme):
    Én egy olyan kimondottan fejlesztőknek szánt rendszeren dolgozom immáron 3 éve, amely ötvözi az ObjectPascal (egy általam kidolgozott variánsát) RAD eszközzel megtűzdelve, a webes platform meghódításával. A fejlesztésem közel 3 évig csak a rendszer elméleti kidolgozásából állt, amit sok-sok magamnak készített specifikációban rögzítettem. És kb. 2 és fél hónapja kezdtem bele a projekt talán legfontosabb elemének, a fordítónak az implementálásába. Ha ez kész lesz, akkor nekiesek az osztálykönyvtárak és komponensek fejlesztésének, ami szintén sokáig el fog majd tartani, de nem lesz vészes, mert a fordító addigra már meg lesz alá. És ha a minimális libek is elkészültek, akkor fogok majd neki egy komplett RAD eszköz fejlesztésének, ami külsőre hasonlóan fog kinézni, mint a néhai Delphi6.

    Minek mégegy Pascal fordító?
    Na ezt a kérdést mindenki feltehetné, még azok is, akik nem szkeptikusak. A válasz a lefordított kimenet mivoltában rejlik. Sokáig vacilláltam azon, hogy a fordítóm x86(-64) architektúrájú kódot csináljon-e, de megadtam magam; a Delphi és főleg a FreePascal fordítója már olyan profi, hogy azt felülmúlni szinte lehetetlen. Ezért azt találtam ki, hogy nem binárisokat (azaz nem natív vagy menedzselt gépi kódot) állít elő a fordítóm, hanem szkripteket. Mert ezek már világszerte el vannak terjedve, szinte minden fejlesztő ismeri őket, így elmondható az, hogy szinte bármely szerveren telepítve vannak. Vagyis nem találom fel újra a kereket, hanem csak alkalmazom.

    A fordító olyan lesz, hogy választani lehet a kimeneti szkriptnyelvekből (PHP, Perl), és az idő előre haladtával ezek listája bővülni fog majd. Ehhez persze hozzá kell még érteni a kliens oldali (X)HTML, CSS és JavaScript kódot is, mert a fordító ezek egyvelegét generálja majd le. Az lefordított webalkalmazás AJAX-szal beszélget majd a szerverrel (de ez is állítható egy fordító direktívával AJAX, jQuery().load(), és háttérben működő IFRAME megoldások közül), mely kommunikációról a fejlesztés során a programozónak nem kell gondoskodnia, ez a fordító dolga lesz.

    Kiemelnék néhány "ficsőrt"/érvet, hogy miért jó ez így:
    - A programozó elől a rendszer teljesen elfedi majd a kliens/szerver programozásmikéntjét. Azaz ugyan úgy lehet majd benne programot írni, mintha az egy hálózatot nem is használó, önmagában álló desktop alkalmazás lenne. Ez nagy mértékben segíti a programozás során az üzleti logika egyben tartását, mert nem kell funkcionálisan szétdarabolni kliens/szerver kódra az egészet.

    - Végleg megszűnteti a böngészőháborút a programozó részéről. Ugyanis fejlesztés során csak azzal kell törödni, hogy mi hogy nézzen ki, meg hogyan működjön, azzal már nem, hogy az egyes böngészőkhöz külön stuff-ot kellene írni. Ha azt mondom egy szövegdobozra, hogy legyen 200x200 pixel méretű, mely pozícióját automatikusan foglalja el, és egy onClick() eseményt is főzök hozzá, akkor nem lesz több dolgom vele, mert a fordító az általa támogatott böngészőkre optimalizálja a kódot (a végterméket). Klasszikus példa az IE6-ból hiányzó :hover CSS-beli pseudo-class, melyet a fordító majd onMouseOver és onMouseOut Javascript eseményekkel emulál majd IE6-on. Fejlesztéskor a programozónak nem is kell tudnia, hogy ezt a fordító hogy oldja meg; a lényeg, hogy úgy működik, ahogy a programozó szerette volna.

    - A Pascal nyelv híres az erős tipizáltságáról. Ezt a tulajdonságát az én Pascal dialektusom is képviseli, vagyis a programozás során (azaz már design time) kiderülnek a hibák nagy része, így mire a kód lefordításra kerül, nagy esély lesz rá, hogy az hibamentes. Illetve olyat is tudni fog a fordító, hogy ha egy feltétel sosem teljesül (ez lehet ciklusfeltétel is), akkor annak blokkját le sem fordítja; warning szintű üzenettel tájékoztatva a fejlesztőt. Ennek logikáját igyekszem minél okosabbra csinálni (asszem ProLog-ot fogok alkalmazni, a bonyolultabb feltételeknél).

    - Maga a HTML nyelv köztudottan nem arra készült eredetileg, mint amire ma használjuk. A HTML csak egy leírónyelv lenne, amolyan dokumentum-formátum. A fordítóm ezt a filozófiát követve olyan kimenetet produkál majd, ami egyáltalán nem tartalmaz majd egyetlen felesleges szóközt vagy tabot sem, csak annyit, ami szükséges (az oldalletöltést némileg így gyorsítva azzal, hogy csak a lényeget tölti le a böngésző, a sallangot nem). Bár így ember számára szinte teljesen olvashatatlan lesz a lefordított kód, de a HTML amúgy sem arra készült, hogy azt minden jött-ment elolvassa, ez legyen csak a böngésző dolga. A fordító azzal is igyekszik majd az oldalletöltést gyorsítani, hogy amennyire lehet összeintegrálja majd az összes éppen használt PHP, HTML, CSS és JavaScript kódot, hogy ne kelljen a böngészőnek kis-milliószor új letöltést indítania, mire össze tudja rakni az oldalt.

    - Az elkészülő RAD eszköz lehetőséget nyújt majd a kód fullos debug-olására, valamint a csoportos fejlesztést is elősegíti majd azzal, hogy olyan kódot állít elő, ami lehetőleg minél inkább elszeparálja a különböző fejlesztők azonos projekten végzett munkáját. Például ha az egyik fejlesztő elvét egy pontosvessző hibát, akkor sem borul majd az egész készítendő oldalrendszer, hanem a hiba csak az adott fejlesztő kódjában jön majd ki. Persze ez alól kivétel, ha a fejlesztők egymás kódját, mint interfészt érik el, de ebben meg szintén nagy segítség lesz a beépített automata verziókezelő.

    - Komplett példakódokat írok majd a leggyakrabban használt eszközökre, melyeket a programozó szabadon tovább bővíthet majd azokból való származtatás után. Ilyenek pl.: CMS, képgaléria, webáruház, blogmotor, stb...

    - A programozó a háttérben használatos adatbázisműveleteit majd el fogom fedni egy köztes osztálykönyvtárral, amely a kompatibilitást biztosítja majd a különböző DB motorok között (MySQL(i), PgSQL, MSSQL, Oracle, stb...). Ez valami hasonló lesz, mint az ADO, bár egyelőre csak remélni tudom, hogy hasznos lesz majd, nem csak átok.


    Na szóval ez az én igazi fejlesztésem, mely éppen ott jár, hogy az implementálása is alig kezdődött még meg. Majd csak akkor akarok vele a nagyvilág előtt előrukkolni, ha már lesz is mit felmutatni, nem csak elméletben, hanem a gyakorlatban is. A probléma csak az, hogy egyedül csinálom, és csak akkor, ha éppen szabadidőm engedi. Vagyis nagyon lassan haladok egyről a kettőre, de külső segítséget addig nem akarok igénybe venni, amíg legalább a fordító el nem készül.

    Ez lesz az én életművem (ne szomorítsatok vagy kedvtelenítsetek el! Nagyon sok munkám van már benne, és be is akarom fejezni, ha már elkezdtem.).


    Szerk.:
    Természetesen tiszában vagyok vele, hogy a dolog csak akkor válik sikeressé, ha készül mögé egy ütőképes API/lib/osztálykönyvtár, és persze azt is tudom, hogy azt majd jómagam nem fogom tudni egyedül megoldani, így ahhoz majd más fejlesztők segítségét is kérni fogom. Lehet, hogy majd nyitok is erről egy külön társalgó topikot itt a Prog.Hu-n. De erre majd akkor akarok csak visszatérni, ha a fordítóm már jól működik...
    Mutasd a teljes hozzászólást!
  • en kezdokent csinaltam egy Kalkulatoros progit (konzolos progi) amibe beadol egy sor szamitasi feladatot es kiszamolja
    meg egy kezdetleges Interpretert is c++-ban, ilyen Pascalos kodszeruseget lehetet bele irni (ezenkivul volt egy par kisebb progi is)
    Mutasd a teljes hozzászólást!
  • Sziasztok!
    Gondoltam nyitok egy ilyen témát, hogy el lehessen dicsekedni, hogy mi a legújabb iromány, program/weblap, esetleg ha publikus akkor a program/weblap, netán a forrásfájl. esetleg egy kis mese róla (mire való, miért/kinek készült, mit tud? A programozás buktatói, volt-e pofára esés, ha igen akkor a megbízótól, vagy puszta figyelmetlenségből, stb... ).
    A moderátoroktól elnézést kérnék akkor, ha ilyen téma már létezik...
    Üdv.: Laci
    Mutasd a teljes hozzászólást!
Címkék
abcd