[Viszont, ha a doksi egérkattintásnyira van, akkor kényelmesebben és gyorsabban haladhatok a programozáskor. Ja, ezert talaltak ki ezelott 30 evvel a man-lapokat.]
Nezzuk a robotos peldadat: Van egy robotod, akire boviteseseket lehet szerelni... nyilvan ehhez a vezerloprogramjat is boviteni kell, eddig ok.
Ket fo eset lehetseges: vagy elore elore interface van, vagy nincs. Ha van (pl Indulás, Megallás, Gyorsítás, Fordulás), akkor nincs szukseg mesterseges intelligenciara, ha viszont nincs, akkor honnan a nyűből talalja ki a kozponti agy, hogy mikor kell meghivnia pl a 'KerékFelpumpálás' metodust (noha tudja hogy mik a parameterei)
Kedves NevemTeve ! (206)
"a dokumentacio az embernek szol" OK. Viszont, ha a doksi egérkattintásnyira van, akkor kényelmesebben és gyorsabban haladhatok a programozáskor. Amennyiben jól kategorizált adatokat helyezek el ebben a leírásban akkor funkcionalitásbeli segítséget is adhatna a gép (az, hogy az előbb használt objektum után milyen lépéseknek lehet értelme /reális esélye/) ... és ha mesterséges intelligenciát szeretnék objektumalapon felépíteni, akkor szüksége lehet rá.
"miért" hm.hm. nehéz dió. Mert ha mondjuk én vagyok mikrobi és kapok (rám kapcsolnak) kerekeket, akkor gyorsabban fogok tudni haladni (és nem okoz nehézséget a megvezérlése). Ha kapok egy párhuzamos portot, akkor esélyem lesz kinyomtatni a dokumentumot. Ha kapok egy illesztőt, akkor belekukucskálhatok a XYZ adatbázisba (*.doc ;-) ) is vagy "adatot" cserélhetek a CYC-el. …stb. szóval MI-nk (- a mi céljaink szerint- pontosan definiált) eszközt kap a saját céljainak eléréséhez.
A célokkal még gondjaim vannak. Elégséges tud lenni az, hogy - megfelelő paraméterekkel rendelkező- végállapot?
mikor Amikor az igény felmerül. (belső állapotjelzések okozataként, kapcsolati eseményekként)
Kedves ResetGomb !
"A tudomány rovatban van egy topic, amiben ugyanezt vizsgáltuk más aspektusból." Tudom, olvasom azt is.
"Lényege, hogy minden objektumot és metódust szabványosítani kellene." Szerintem is. Kiegészítés: már amennyire lehet (értelme van).
"Ennek a munkának az elvégzésére senki sem jelentkezett. :-((( " Ház izé, Én próbáltam errefelé hatni, de nem találtam kellő fogadtatást ezért nem erőltettem, meg egyébként is ide - ebbe a témakörbe - való téma. A többi lényegtelen. . . . Akkor most elkezdhetnénk. Egyébként e folyamatsorban való előbbre jutás során - akár konkrét - megoldást adhatunk az AndrisK-nak. Sőt szerintem az tovább is fog vezetni. Az alapvető céljaink azonosak - az általános céljaink meg nagyjából - csak én más megvalósítási utat járok (képzelek el).
Kedves pasa_! (209)
" de erre csak AI alkalmazasban latnek igenyt." Én is. Bárt ezt egy lépéssel később szerettem volna megbolygatni.
"az objektumnal 'futasidoben' lehet az eljarasokat hivogatni -- beleertve azt, amelyik a doksit eloallitja.
A programot meg _elobb_ szoktuk megirni, es csak utana futtatni." Azt hiszem már hallottál te is a soronként fordító interpreterekről. … de ezt inkább később.
"Menet kozben a program megkerdezheti ugyan hogy mit tudnak a reszei," Speciel ezt nem menet közben kellene, hanem előtte. De mi is az a menet közben? Az előttét úgy értem, hogy a sMI (AI) ismeri a megoldási alternatívákat, amikből válogathat. Mind a válogatáshoz, mind a megoldások felépítéséhez tudnia kell a rendelkezésre álló eszközeiről. … ezt is inkább később.
Kedves Bandi-T ! (214)
Látom igen előre szaladtál te is. Örülök neki.
"nagy elemszámú felhasználási területeknél érdemes választani (és valóban, használják is nem egy helyen)" Hol? Mit? Mivel? Hogyan? Kérlek írj róla.
"visszajutunk ahhoz, hogy bár az interfész (a hogyan) formalizálható és így kezelhető" Erre szeretnék egy ismertetni egy elgondolást, melyet VELETEK lehetne megoldani, finomítani, letisztázni. Ennek lenne első lépése az, hogy a kívánatos adatok elérhetőek legyenek.
Mivel ez "kötött problémakör," előbb- utóbb a végére is érhetünk.
Nézetem szerint a "'mikor' és a 'miért'", nem emberfüggő megfelelően alkalmazható a MI-ben (ki fog jönni a MI-ből).
Mivel a MI nem rendelkezik "az 'emberi kreativitás' "-al, ezért CSAK egy racionálisan gondolkodó herkentyű lesz. (Hú: ez utóbbi két mondatot nem kéne tovább vinni, mert messze vezet, és igencsak hit és ismeretanyag kédése.)
Kedves Tervezők!
Még vannak megválaszolatlan kérdéseim. Kaphatnék rá válaszokat! (csak azért mert lassan haladok)
Cyc tulajdonképpen egy 'önjáró következtetőgép': bizonyos alapvető logikai ('gondolkodási') módszerek segítségével folyamatosan rendszerezi a betáplált adatok alapján a világról alkotott képét, és ha kell, visszakérdez, pontosítást kér - így tanul, próbálja elsajátítani az emberek világról alkotott közös képét, próbál 'józan észre' szert tenni a rengeteg menet közben ráöntött szakismeret mellett. :) [Kósza topicolvasóknak: Cyc természetesen nem tudatosan gondolkodó lény, hanem pusztán egy rengeteg információval rendelkező számítógépes rendszer.]
Az eredeti felvetés kivitelezhető részproblémájaként elképzelhetőnek gondolok egy olyat, hogy bizonyos domaineket (na igen, de miket?) megfelelően modellezünk, és ezeken a domaineken belül valamilyen útkereső, költségminimalizáló módszerrel képesek leszünk a jelenlegi paradigma szerinti objektumosztályok és azok metódusainak kombinálásával eljutni egy kitűzött célig.
Egy - remélhetőleg közérthető - példa: van A képformátumom, és el akarok jutni Z képformátumig; ha van jegyzékem az összes x->y képformátumkonverziós függvényről/objektumról (most hatásvadászok: akár egy óriási központi Internetes objektumjegyzék), akkor a jegyzék segítségével felállíthatok egy gráfot, amiben valamilyen költségfüggvénnyel megkereshetem a legalacsonyabb költségű utat (konverziósorozatot), beszerzem az ahhoz szükséges objektumokat és elvégzem a konverziót; sőt, az objektumokat magukat akár nem is szerzem be, hanem közvetlenül nekik adom át a konvertálandó adatot - ez utóbbival például eljutottam a klasszikus távoli eljárás- (RPC), illetve objektumhíváshoz.
A fenti körnek lehet annyi előnye, hogy bizonyos zárt és ezért megfelelő alapossággal modellezhető de nagy elemszámú felhasználási területeknél érdemes választani (és valóban, használják is nem egy helyen), de nyitott problémakör esetén megint visszajutunk ahhoz, hogy bár az interfész (a hogyan) formalizálható és így kezelhető, mert az is egy véges, kötött problémakör, a 'mikor' és a 'miért' számítógéppel csak az 'emberi kreativitás' objektum megfelelő számítógépes modellezése után lesz majd hatékonyan megközelíthető. :)
Még mindig nem értem, mire jó az üzenetek_száma tábla: mennyiben hatékonyabb, mint az általam javasolt topicok tábla? Ráakasztottad a topicnak még néhány attribútumát (create_date, first_msg_date, first_user_id, last_msg_date, last_user_id) - ez szigorúan véve valóban több információ, mint az általam javasolt topicok táblában, azonban a példa (lekérdezéskor aggregálni vs. aggregálttal egyenértékû adatot mozgáskor frissíteni) szempontjából nem hoznak újat, úgyhogy gondolom nem ezért mondod rá, hogy elegáns, informatív, takarékos és még megoldás is.
Mint ebbõl is látszik tehát, nem értem, hogy megközelítésében/hatékonyságában hogyan jobb az általad javasolt üzenetek_száma tábla, mint az általam javasolt topicok tábla.
Ezt írod: minden topic minden rekordjában van egy szám, ami az aktuális üzenet előtt az adatbázisban szereplő üzenetek számát reprezentálja - umm, nem sikerül megtalálnom, hogy hol javasoltam ezt. Hol javasoltam ezt?
Ez most rossul esett. Kérlek kedves indextc2, ne kezdj el személyeskedni; inkább, még ha csak röviden is, magyarázd el, hogy mire gondolsz. Valóban nincs valami óriási tapasztalatom, de azt képzeltem, egy kicsit azért értek hozzá.
szvsz az objektumnal 'futasidoben' lehet az eljarasokat hivogatni -- beleertve azt, amelyik a doksit eloallitja.
A programot meg _elobb_ szoktuk megirni, es csak utana futtatni.
Menet kozben a program megkerdezheti ugyan hogy mit tudnak a reszei, de erre csak AI alkalmazasban latnek igenyt. :)
Btw a COM rendszerben van ilyen info lehetoseg, meg kozos borzer is mint OLEVIEW. meg OLE test container.
En is gondoltam ra, hogy utalni kellene erre a "filozofikus adatbazis"-topikra, csak eppen ott sem talaltak meg valaszt a (206)-ban feltett kerdesemre... gepileg kezelheto hogyan, de ember kell ahhoz, hogy a mikor illetve miert kerdesre valaszoljon.
[Termeszetesen ha egy elore megadott interfacet kell megvalositani, akkor nincs semmi problema (pl bovitsuk a linux kernelt egy ujabb hangkartya tamogatasaval), de most eppen nem errol van szo]
Namost a gond az, hogy a dokumentacio az embernek szol, a metodushivas meg a programnak, tehat ennek a kettonek az osszemixeleset nem latom celravezetonek...
Masik dolog amit emlitesz, az automatikus felismeres. Az rendben van, hogy a rendszer befogad egy uj objektumot uj metodusokkal, megerti hogyan kell hivni az uj metodusokat, csak azt nem tudja, hogy miert jok neki ezek az uj metodusok, tehat milyen alkalombol kellene meghivni oket.
Kedves Tervezők. Miért nem hirdetik magukat az objektumok?
Amikor az ember véletlenül összefut egy-ismeretlen objektummal, mondjuk egy objektumtallózóban, és keres valami - már mások által megírt (és hogy nekem ne kelljen) - szituációt, azt igencsak nehezen találja meg.
Egyedüli eligazodást csak az objektumok nevei adnak, már ha adnak. Meg egy keveset a paraméterek száma és milyensége. Amíg egyszerű problémákra keresünk megoldásokat, addig elégségesek tudnak lenni a fejben tárolt információk. Mihelyst egy nagyobb objektummal futunk össze, nem tudunk meglenni dokumentációk (helpek, referencia leírások) nélkül.
Mi lenne akkor, ha a hiányzó információkat maguktól az objektumoktól lehetne megkérdezni, maguk az objektumok mesélnének önmagukról.
Ehhez nem is kellene túl sok mindent tenni, csak fel kellene venni egy - mindenki által egyformán használt metódust, ami teljesítené ezt a vágyunkat.
Tehát volna egy függvényünk, amitől kérdezni lehetne, és ezáltal okosodhatnánk. Itt nem a hagyományos HELP leírásra gondolok, hanem valami másra, amit aztán automatizálni is lehetne.
Ezzel a tudással felruházott programok képesek lennének ismeretlen objektumokat fogadni és használni. ... hmhm Ez így nagyon általános és nagyképű. A fogadás - nagyjából - egy nyilvántartásba vétellel elintézhető, viszont a használat ettől azért többet takar, ami feltételez egy fogadó közeget, egy "megértő-t" és a küldött, lekérdezett anyagot, mint "megértendőt".
Nos: ÉRDEKELNE A VÉLEMÉNYETEK, valamint segítséget szeretnék kérni a kidolgozáshoz.
Mi legyen ennek a metódusnak a neve? Hogyan kelljen használni, (milyen paraméterekre milyen tartalmakat szolgáltasson). Milyen tartalmat is kell megértetnem a fogadó programban? Csak egy általános leírást? Csak a folyamatábrát? Vagy ezeket mind és még mást is? Netán magát a programot is? A "komment"-tekkel mi legyen? Ezeket a tartalmakat, hogyan lehet leírni, és hogyan kell szervezni, hogy algoritmizálható legyen a hozzájutás.
Ui: Szerintem, az ilyen objektumok aktívan tudnák segíteni a programozást (mely kicsit átalakul), és óriási mértékben meg tudná emelni az újrafelhasználhatósági képességet (merthogy igény az volna rá, de a megvalósítása még csak a kályhánál jár).
… esetleg önálló fórumot nyissak neki? …vagy nem ér ennyit az egész?
Azért ha kényes vagy az optimális kihasználásra, akkor az üzenetek_száma táblát hozod létre mondjuk így:
topic_id, message_nb, create_date, first_msg_date, first_user_id, last_msg_date, last_user_id, stb.
Ez topic-onként egy rekord és több információt ad, kevesebb tárterület árán, min ha minden topic minden rekordjában van egy szám, ami az aktuális üzenet előtt az adatbázisban szereplő üzenetek számát reprezentálja. Elegáns, informatív, takarékos, és még megoldás is. :-D
Szerintem egyáltalán nem érdemes ragaszkodnod a 'nincsenek redundanciák az adatbázisban' követelményhez.
Hadd hozzak egy egyszerűsített példát. Tekintsünk egy fórumot, ahol vannak topicok, és a topicokon belül üzenetek. A topicok listázásakor szeretnénk kiírni az bennük levő üzenetek számát.
Ha egyáltalán nem tűrünk redundanciát, akkor az alábbi adatmodellt alkalmazzuk:
üzenetek: üzenet_id, topic_id, szöveg
topicok: topic_id, topic_neve
ilyenkor viszont kénytelenek vagyunk a topicok listázásakor minden alkalommal minden kilistázott topichoz az üzenetek táblából aggregálni kell (jelen esetben össze kell számolni) a hozzá tartozó üzeneteket - ez futásidő szempontjából rendkívül pazarló eljárás.
Nem vesztünk sokat a redundanciából, ha módosítunk, így:
üzenetek: üzenet_id, topic_id, szöveg
topicok: topic_id, topic_neve, üzenetek_száma
ilyenkor új üzenet érkezésekor (vagy üzenet törlésekor) ugyan két műveletet kell végezni, mert módosítani kell az adott topic üzenetszámlálóját (célszerűen triggerből) is, viszont utána a topicok listázásakor aggregáció nélkül rögtön ott a kért aggregált adat.
Ha várható, hogy lekérdezésből lesz több, és nem üzenetmozgásból (vagy mondjuk úgy, nem lesz nagyságrendekkel több mozgás, mint lekérdezés), akkor ebben az esetben egy kis redundancia árán megvásároltunk egy jelentős teljesítménynövekedést.
A te konkrét alkalmazásod esetén általában mennyi mozgás, és ehhez képest mennyi lekérés van?
Mit jelent, hogy 'Egy adott anyag összes tétele időrendben összesen illetve egy adott raktárra.'?
A problémát az okozza, hogy a honnan_id, hová_id ugyanabból a választékból kerülnek ki: szállítók, vevők, igénylők, raktárak. (Ugyanannak az egyednek -partner - két különböző szerepben való megjelenése.)
Ebből a táblából kell előállítani két listát:
- anyagkarton
Egy adott anyag összes tétele időrendben összesen illetve egy adott raktárra.
- forgalmi karton
Egy adott partner (vevő,szállító, igénylő, ...) összes forgalmi tétele időrendben.
Ezek olyan listák, aminek kérés esetén szinte azonnal meg kell jelennie a képernyőn.
Mi lenne az optimális adatszerkezet?
(Optimálisnak azt tekintem, ha a fő tábla rekodjai indexeken keresztül 100%-os találati pontossággal elérhetőek, nincsenek redundanciák az adatbázisban, egy új forgalmi tétel egy új sort generál a fő táblában.)
Hihetetlenül szarul, ugyanis elszállt mind a két vincseszterem, most próbálom menteni a menthetőt - rajta volt ugyanis a diploma munkám, alig pár oldal hiányzott. Mondjuk megvan kinyomtatva, de újra begépelni, azért nem lenne nagy öröm..
Államvizsgára meg még tanulok :)
Átok hardver, tényleg kell a gépbe? :))))))
Informatikai nirvána nincs, csak valamiért senki nem akar írni ide.
Na mi a helyzet? Mindenki tokeletesen megtervezett szoftvert csinal, az osszes ugyfel elegedett, itt az informatikai nirvana? :)
kedves despil_hun,
'Nos, mivel jelenleg diplomámat csinálom - államvizsga közelg :)))) -, ezért van időm ilyennel foglalkozni, és még hasznos is, mert az államvizsga B tétele szoftver témájú, az A pedig hardver. '
Engem az is érdekelne, hogy egy termék-folyamat pároshoz csak egy megelőző folyamat tartozhat?
Vannak esetleg elégazások, két vagy több folyamattól függő folyamatok, mert ez nem derül ki egyértelműen, és annyira nem lényegtelen szerintem.
