362
-
cylontoaster #242 Jobb helyeken nem kapsz el clear text jelszót. Vagy a kapcsolat titkosítása miatt, vagy már eleve a hash közlekedik csak. Az viszont egy (elvileg) random számokból álló sorozat, illetve annak néz ki. Ha mintát találsz a hash-ben, akkor nagyon gazdag leszel :) -
A1274815 #241 Jó a winyó egy példa volt, de titkosított üzenethez, nem kell fizikailag hozzá férni, elég virtuálisan. Az meg minden féle képpen meg van az internet világában.
Utoljára szerkesztette: A1274815, 2017.12.14. 22:12:20 -
gforce9 #240 Hát ha már valamihez fizikálisan korlátlanul hozzáférnek, már régen rossz :) -
A1274815 #239 " Kivéve a ha a távoli számítógép 3 után azt mondja, hogy anyádat, próbálkozz 10 perc múlva :) "
Milyen távoli számítógép? Nem jelszót törsz (az amúgy sem véletlen szám, még csak nem is pszeudó véletlen), hanem elkapott titkosított üzenetet vagy ellopott winyón titkosított doksikat. -
cylontoaster #238 Először is, szerintem ne ismerje fel hogy gyerek, mert tökre felesleges a programnak ilyenekkel bajlódnia :P (Honnan ismeri fel? Alacsony?)
Nézze meg hogy van-e lehetőség félrerántani a kormányt. Ezt egy értelmes program folyamatosan monitorozza, így abban a pillanatban hogy észlelte az eléugrókat máris tud dönteni néhány bool értékből (esetleg lehet ennél bonyolultabb, pl nem boolean hanem egy szám, hogy merre kormányzás mennyire "jó", így tud dönteni akkor is ha több lehetőség van (ha így is egyenlőség van akkor az első), persze nem elfelejtendő hogy az ugrálók miatt változtak a lehetőségek (a relevánsakat újra kell értékelni)).
Filozófiai vitákat meg előre törvényben el kell dönteni. Azaz legyen kimondva és úgy kezelve, hogy az a prioritás aki az autóban ül, vagy pont fordítva. Ha a kérdés a filozófiai helyzet eldöntésére vonatkozott, az baj :D
Leginkább lehetne a gyorsabb sávokat/útvonalakat fallal körülvenni, ahol nem ugrálhatnak eléd. Ahol lassabban közlekedik ott pl. bevállalható egy falnak menés, mert a kocsiban ülő védettebb. -
gforce9 #237 "1 milliárd kulcsot elviselhető időn belül, ők igen."
Kivéve a ha a távoli számítógép 3 után azt mondja, hogy anyádat, próbálkozz 10 perc múlva :) -
A1274815 #236 "Ha mintát fedezel fel, akor nagyobb esélyed lesz az eltalálásra."
Nem, mert valódi véletlen számoknál (amelyek kvantum fizikai eredtűek, már pedig a termikuszaj, sörétzaj, (elektrónika)fehérzaj ez a kategória) hiába látsz mintát, a következő számot akkor sem tudod garantálni még az sem, hogy a te általad megbecsültnek a közelébe essen, jobban mint a minta ismerete nélkül, mivel, és itt a lényeg(!), nem függ az előzőtől, ellenben a pszeudó véletlen számnál, ahol az előzőből generálják az újat.
" A kulcsszó amit mondtál te is, hoyg 1 milliárd kulcs kipróbálása, ami nem éri meg."
Neked nem, az NSA-nak igen. Nem véletlen volt még a Linux kernelben is "meghackelve" a véletlenszám generátor az RSA-hoz. Te nem tudsz végig próbálni 1 milliárd kulcsot elviselhető időn belül, ők igen. -
cylontoaster #235 Ez már szőrszálhasogatás. Felírhatom papírra hogy a kör területe mi, ezt megszorozhatom hattal meg eloszthatom kettővel, de itt szerintem nem számoltam irracionális számmal.. Ha ténylegesen ki akarom számolni a területet, akkor papíron is csalni fogok és kerekítek(vágok).
Ha tudok úgy trükközni hogy kiesik az irracionális szám, akkor megint nem számoltam vele, ahogy ilyen esetben a program sem fog.
Nyilván vannak eltérések gépi szám és "valós" közt, viszont ezt előre lehet tudni, ergo a tervezésnél figyelembe lehet venni. Ha ebből fakad a hiba, akkor az pont olyan mintha balra helyett jobbra menne az autó. Mindkettő ki kell derüljön teszteléskor vagy felülvizsgálatnál. Ha bazisok idő után nem kerül elő a probléma, akkor olyan kicsi az esélye a meghibásodásnak, hogy biztosan jobb, mint ha élő emberek vezetnék. És változatlanul lekezelhető. (És ha 10 évente lesz egy baleset az önvezetők miatt, akkor már megérte.) -
gforce9 #234 Ha mintát fedezel fel, akor nagyobb esélyed lesz az eltalálásra. A kulcsszó amit mondtál te is, hoyg 1 milliárd kulcs kipróbálása, ami nem éri meg. Tehát gyakorlatban jól alkalmazható védelem, de elméletben kellően sok minta után következtethető. Utóbbi nyilván soha nem fog megvalósulni, így a kulcsunk biztonságos. -
A1274815 #233 Ebben akkor lenne igazad, ha nem csak a zajt tartottam volna meg hanem még pár paramétert.
Mintákat fel lehet fedezni, amúgy a teljesen véletlenszámokban is, azt hívják eloszlásnak. De hogy a korábbi minták ismerete alapján, nem fogod tudni nagyobb valószínűséggel eltalálni a számot, mint nélküle az is hót zicher, ellenben a pszeudó randomszám generátórnál. Ott elég ha csak az NSA ránéz az órájára és mindjárt tudja, hogy melyik 1 milliárd "véletlen" kulcsot kell kipróbálnia. -
gforce9 #232 " Perpill ugye a sofőré a felelősség, aki az önvezetőt használja."
Én nagyon nagyon reménykedek abban, hogy ez így is marad. Mert ez legalább jogilag tiszta. Majd utólag ha megfizette a kártérítést, a gyártóval úgy meccseli le a dolgot, ahogy tanulta.
De mi a véleményed aról a felvetésemről, hogy lelép eléd 3 gyerek szabálytalanul féktávon belül. Mit tegyen az autó automatikája? -
cylontoaster #231 "Ezért sincs sehol a világon olyan rendszer, ahol kizárólag számítógépre bíznának emberi életeket, emberi felügyelet nélkül."
Kötöttpályás közlekedés? Itt komplexebb a feladat, de alapvetően mennyiben más? Távoli vészleállítás lehetőségét ebbe is be lehet írni. Egy központi rendszer figyeli hogy az autók a térképen feltűntetett sebességhatároknak megfelelően mennek-e és szól a központosoknak, ha nem.
Alighanem bőven van még olyan példa, ahol elvileg van ember, gyakorlatilag a gépekre vannak utalva. Ha a gép hülyeséget mutat, akkor az ember ennek megfelelően hülyeséget fog tenni. Légiirányítás, orvosok, közlekedési lámpa, stb.
Ennél sokkal érdekesebb az, hogy ez hogyan lesz szabályozva. Minek kell egy önvezető autónak megfelelnie, illetve milyen felelősség lesz. Ha hülyeséget csinált az autó, akkor ki lesz a felelős és milyen következményei lehetnek. Ettől függ az, hogy mennyire lesz tesztelve, illetve egyáltalán van-e valaki aki felvállalja ezt, és készít ilyet. Perpill ugye a sofőré a felelősség, aki az önvezetőt használja. -
A1274815 #230 Van benne különbség. Mert úgyebár ott vannak azok a speciális esetek, amiket írtam + papíron is tudsz irracionális számokkal számolni, mint szimbólumokkal, van hogy késöbb kiesenek, ellenben ha long double (x86/x64 FPU regiszerei ilyenek) típussal végigszámítod pontatlanabb eredémnyt fogsz kapni, mint papíron, mert az nem fog neked srqt(2)pi-t szimbolikusan összeszorozni, hanem csak ténylegesen. Egyébként meg maga a 2 sem ábrázolható pontosan, hanem helyette 1.9999999999996 kerül az FPU registerébe. -
gforce9 #229 Az a baj ezzel, hogy minták felfedezhetőek akkor is. Teszemfel az általad leírt módszert alkalmazzuk amely módszer egyik paraméterére hatással van mondjuk a napfolttevékenység. Épp csak icipicit, ki nem mérhetőt, de mégis. Heti lottóhúzásnak elmegy a generátor.
De mondjuk 100 milliárd előállított számot alapul véve szabályosságot lehetne felfedezni és ha mást nem, azt ki lehetne deríteni, hogy honnan vetted a paramétert :) A statisztikai fizikában vannak erre finomságok. Kellően sok mindtavételezésből elképesztő, hogy mikre rá nem lehet jönni. :)
Utoljára szerkesztette: gforce9, 2017.12.14. 21:37:48 -
A1274815 #228 "Egyébként a véletlenszámgenerátorod sem véletlen, mert amit a környezet paramétereiből állítunk elő, az nem véletlen, hanem az aktuális paraméterekből egy algoritmussal előállított szám."
Kivéve, ha a környezet kvantum mechanikai folyamatai által okozott zaját vesszük csak figyelembe. Típikusan valamilyen ADC-vel mért valós fizikai paraméter legkisebb helyiértékű bitje. Abban viszont igfazad van, hogy ezt ritkánszokták használni, helyette pszeudo vélatlen szám generátorokat használnak, mert egyszerűbb + kell az NSA-nak is esélyt adni meg a szomszéd Pistikének is.
-
cylontoaster #227 Biztosan nem abban rnák meg, de pl az Ada kimondottan ilyen jellegű feladatokra van.
De leginkább egy ilyen komplex programot nem egy kódban írnak meg. De nem hiszem, hogy ez releváns..
A nagyobb rendszerek tervezése úgy néz ki, hogy nézed az összképet és rekurzívan lefelé egyre kisebb feladatokra bontod.
Adott 3 külön részleg, más-más részfeladatokat végeznek el. Te megtervezed hogy melyik mit végezzen el (magas szinten), illetve azt, hogy a részlegek által egymásnak átadandó adatok, illetve A rész által írt fv, B rész által írt kódja során mehívandó fv-ek hogy legyenek. A rész megír mondjuk 3000 fv-t, ebből 50 publikus (azaz olyan amit B vagy C rész meghívhat), amiből 20 képes arra, hogy az A által létrehozott adatokat írhassa (előre megadott kondíciók szerint, azaz pl. nem lehet a sebesség 500).
Az(ok) akik átlátják az egészet, azok is csak magasszinten, mert nem kell mélyebben. Akik 1-1 részt csinálnak, azok nem látják a többi részt, csak a nekik relevánsat. Mint amikor házat építesz. Te nagyjából tudod milyen házat akarsz, de baromira nem tudsz részletekbe belemenni, fogalmad sincs milyen anyagból legyen a vakolat, milyen vastag legyen az alap, stb. A részfeladatokat kiadod különböző szakiknak, akik magasszintű tervrajz alapján a saját feladatukat megcsinálják. Mindezt úgy, hogy nincs senki aki pontosan átlátna mindent (=egyedül meg tudná csinálni a házat.
A hibakezelésnél a try-catch pl az előre nem várt hibák lekezelésére is alkalmas. Ha így hívsz meg egy függvényt, akkor futás közben dobálhatsz vele hibát (pl. nem megfelelő értéket kapott, vagy túl lassan kapta), amit utána lekezelsz. Ha előre számítottál rá, akkor lekezelheted ennek megfelelően, pl ha az előtted haladó autó sebessége 500-ra lett mérve, akkor (mivel ilyen hibára készültél), meghívod mondjuk újra a fv-t (és elkönyveled hogy 2. hívás volt, elkerülve a végtelenciklust). Ha olyan hiba van, amire nem írtál külön lekezelést (pl. 3. ismételt távmérés is hülyeséget adott), akkor azokat egységesen lekezeled, pl félrehúzódik az autó.
Tök8 miért lett rosszul mérve a sebesség, le van kezelve. Értelemszerűen eleve nem 1x mérsz, és hibaeset az, ha két mérés közt irreálisan nagyot ugrott az érték (pl. nem fog egy tized mp alatt 100-ról 200-ra gyorsulni). -
gforce9 #226 Ahogy látom fordítva gondolkodsz az egészről. Megjegyezném ez gyakori tévhit, hogy a programozót aki megír mondjuk egy böngészőt egy kalap alá veszik egy olyan programozóval, aki fedélzeti számítógépet programoz. Pedig a gondolatmenetük is más. Utzóbbiról fogok írni.
Egy kritikus rendszernél először lefektetik mit kell tudnia. Tegyük fel a példa egy automata fékrendszer, ha eléd kerül valaki lefékezze az autót.
Az autó számítógépében erre fog futni egy programkód. A feladata az, hogy a bejövő érzékelőkből számoljon, hogy fékezni kell e vagy nem. Illetőleg az, hogy pontosan mekkora fékerőt kell alkalmazni a kívánt lassuláshoz.
A futó program a bejövő paraméterekből állapítja meg a fékerőt. Ez az alapműködés.
Mik a beérkező paraméterek?
1. Én vagyis a számítógép hiba nélkül működök? 2 párhuzamosan futtatott ugyanolyan prgram ezt a kérdést kiixeli. Ennél sokkal kifinomultabb módszerek vannak alkalmazva arra, hogy hibát okozó programrészek fussanak, nem megyek bele, de láttál már te is olyat, hogy a windows szól, hogy egy program szarul fut vagy lefagyott. Megoldható.
2. Keréknyomás. Megengedett paramétereken belül van? Ha nem az automaitka kikapcs. Ha igen változott a méréshatáron belül? Ha nem az érzékelő rossz. Automatika kikapcs. Ha az érzékelő hibát jelent szintén.
3. Távolságmérő radar. Távolság mennyit és mennyi idő alatt változott? Szinkronban van e a kapott eredmény a kilóméterórával? Nyilván bármilyen hiba esetén automatika kikapcs.
4. Sebességmérő. Számítási alap a fékezésnél, de szinkronban kell lennie a többi műszerrel akár a radarral, de a GPS-el is. Nem lehet jelentős eltérés.
5. Optikai szenzorok. Szinkronban vannak a radarral? Ha nem automatika lekapcs.
stb
stb
stb
Teljesen más egy kritikus rendszer megtervezése és programozása mint pl. egy böngészőé. Teljesen más gondolkodásmódot igényel.
A cél mindig az, hogy bármiféle hiba történik, az kiszűrésre kerüljön.
Lehet ilyen gonolatrendszer mögött hiba? Persze. De nem komplett egész rendszerként tekintenek az egészre, ha a biztonságról van szó, hanem le kell bontani a lehető legkisebb részegységekre és azt biztonságossá tenni és akkor az egész rendszer (példánkban az, hogy megálljunk, ha elénklép valaki) sokszorosan biztonságosabbá tehető, mintha az ember vezetné.
Erre példa is van:
https://en.wikipedia.org/wiki/Honda_Insight
Ha jól dereng 20 év tökéletesítés van mögötte, de egy kicseszett jó rendszer lett. -
Irasidus #225 Akkor közelítsük meg más oldalról, mert amit mondok az lesöpröd. Ezért kérlek mond el, hogy működik a nagy rendszerek megtervezése. Köszönöm! Szóval azt mondod, nem tudok olyat mondani, amire helyben ne tudnál megoldást? Gondolom nem programozói megoldásra gondoltál, mert akkor meg tudnád írni a programot, igaz? Vagy igen? Akkor, hogy kezdenél hozzá, miben írnád meg, mi lenne az első lépésed? Csak kíváncsiságból...
Utoljára szerkesztette: Irasidus, 2017.12.14. 20:59:56 -
gforce9 #224 Nem hinném hogy tudsz olyan helyzetet mondani egy önvezető autó esetében (etikai kérdéseket leszámítva), hogy itt helyben ne tudnék rá megoldást mondani és nálam sokkal körültekintőbb emberek tervezik őket.
Utoljára szerkesztette: gforce9, 2017.12.14. 20:54:47 -
gforce9 #223 Ezekre megvannak a megfelelő matematikai módszerek. Semmiféle olyan dolog nincs amit ne lehetne kezelni. Nincs egyszerűen olyan dolog, amit egy megfelelően megírt program, akár hibás inputok ellenére is le ne kezelhetne. -
Irasidus #222 Lehet nem értette, de neked viszont meg kellene érteni, hogy nem lehet minden esetben pontosan számításokat kapni, tehát matematikailag pontatlan eredményt fogsz kapni. Mert szerinted 2+2 az mindig 5. Egyszerű esetben talán, de egy nagy komplexitású szoftver esetében már nem, sőt változhat is, hol ez hol az az eredmény jön ki. -
gforce9 #221 Ne haragudj, de nyilvánvalóan látszik, hogy nem sok közöd van a komplex rendszerek tervezéséhez, tényleg minden bántás nélkül. Egyszerűen nem így működik egy nagyobb rendszer megtervezése, ahogy leírod.
Igenis meg lehet egy önvezető autót bolondbiztosra csinálni és az összhibákat messze egy ember hibázási arányának alá szorítani. Hogy még nem tartunk ott? Lehet. Fogunk ott tartani? Semmiféle akadálya nincs.
"Még mindig itt a hiba, hogy valami egyszerű dolognak tekinted a programot, mint a kettő meg kettő. De több a programozás, mint néhány logikai alapművelet"
Nem nem több. Egy program pontosan ennyiről szól. Az a gond, hogy te gondolod többnek. Az, hogy egy rendszert kell összerakni az egy dolog. Ez lehet egy bonyolult összetett rendszer, de a hibák pontosan az alapműveleteknél keletkezhetnek. A kis összetevőknél. Ezeket izolálni kell és kb a négy alapművelet szintjén megoldani a hibát. Mindegyik hiba visszavezethető egy hibás inputra vagy egy rosszul felállított feltételrendszerre (megfelelő programtervezést feltételezve az egész feladatot tekintve.) -
Irasidus #220 Az én válaszom arra vonatkozott, hogy nem lehet tökéletesen futó programot írni, és hogy a programok nem hibáznak. Erre jó példa volt ez, de hibáznak, és nem tökéletesek. Se többet, se kevesebbet nem akartam mondani. Mellesleg van a programozásnak olyan területe mi megoldhatatlan programozási problémákkal van tele, ez is egy tudomány, ami fejlődik. Másrészt a kérdésed más értelmezésében, a világ végtelen számú lehetőségből tevődik össze, amit nem mindig lehet előre látni, hogy mi lesz. Szóval ez esetben a válasz az, hogy vannak előre nem látható problémák, vagy programozásilag megoldhatatlan problémák. -
Irasidus #219 "Mindig lesznek olyan lehetőségek, amikkel nem számolnak,"
Pontosan! Ezért is veszélyes ez a jármű, mert mindenre nem gondolhatnak. Sajnos ez jellemző szokott lenni. Viszont a válaszom nem erre vonatkozott, hanem arra a felvetésre, hogy minden program tökéletes működik, és szerinted lehet hibátlan programot írni, illetve két futás között ugyanazt az eredményt adja. Több okból sem lehet, ezt is beteheted azok közé amit eddig írtam. Köszönöm.
"De a hiba akkor is az apró komponensek egyrendszerben. Hibájuk kideríthető, utána javítható vagy áthidalható vagy kikerülhető. Pontosan jó írod. Van néhány logikai alapművelet és nem több. Ebből áll össze a nagy egész."
Még mindig itt a hiba, hogy valami egyszerű dolognak tekinted a programot, mint a kettő meg kettő. De több a programozás, mint néhány logikai alapművelet, sokkal több, és ettől lesz a végeredmény kiszámíthatatlan sokszor, és nem egy nagy egész, hanem sok nagy egész, egymásba mindenféle bonyolult viszonyban, mint a barátok közt, csak még bonyolultabban. -
gforce9 #218 Szerintem nem :) -
gforce9 #217 Ebbe nem értem miért kellett belekötni, rögtön utána leírta, hogy mi történik........
Egyébként a véletlenszámgenerátorod sem véletlen, mert amit a környezet paramétereiből állítunk elő, az nem véletlen, hanem az aktuális paraméterekből egy algoritmussal előállított szám.
Véletlen a számítástechnikában igencsak fogós ügy. Ellentétes magával a programozás alapvetéseivel. Mindenesetre lehet olyan "véletlenszámot" előállítani, amit az adott feladatra tökéletesen alkalmas és visszafejthetetlen.
Utoljára szerkesztette: gforce9, 2017.12.14. 20:29:18 -
cylontoaster #216 Elolvastad amit írtam? Vagy ennyire félreérthető volt, hogy a kérdés után kifejtettem, hogy miért nem? -
A1274815 #215 "Szerinted soha egyetlen program sem számol irracionális számokkal?"
De nem ám! Az összes program az irracionális számokat egy adott pontossággal megközelítő fixpontos vagy lebegőpontos alakú racionális számokkal dolgozik, még a racionális számok közül is a többség pontatlan. Persze lehet speciális eseteket (x tört kitevős exponensei, pi, e, stb. racionális többszörösei, racionális kitevői) feldolgozni, de ezek megint csak nem általános érvényűek és az elkerülhetetlen konverzió során ezt mindjárt el is veszted. -
A1274815 #214 "mert nem lehet véletlen számot generálni"
De csak be kell vonni a kvantumfizikát hozzá: mérd meg pontosan hány voltot kap a processzor vagy mérd meg mi van a hangkártya bemenetén (feszültségingadozás, sörétzaj, térerősségváltozás, fehérzaj, termikuszaj), majd a legkisebb helyiértékű bitenken kívül dobj el mindent. Végül ismételd ezt meg míg a kívánt méretű (bit számú) véletlen számot össze nem tudod rakni az egy bites mintákból. -
cylontoaster #213 Szerinted soha egyetlen program sem számol irracionális számokkal?
Hogy a búbánatban kapna eleve ilyen számot?
Bizonyos tizedesjegy után le fogja csapni, és máris nem irracionális, pont úgy, ahogy te is tennéd, ha papíron számolnál. Nyilván olyan helyen vágják le, hogy ne méterek vagy másodpercek legyenek a difik. Nem lesz végtelenül pontos, de mondj bármit az életben ami az.. ettől még a program helyes, amennyiben az eltérés elenyésző.
Szerinted felmerülhet olyan probléma, amire nincs megoldás? Ha így lenne, egy ember hogy lenne képes vezetni? (A filozófiai ha ezt választom azt ütöm el, ha azt akkor a másikat jellegű marhaságokat kivéve). Mert ha ilyen probléma nincs, akkor minden esetleg felmerülő rendellenességre eleve fel lehet készülni és le lehet kezelni.
És bármikor megteheti az autó, hogy félreáll.
Egyébként ha iszonyat nagy gáz van és összeomlik a rendszere, akkor mi fog történni? Megáll az autó, ezt időben látja a mögötte lévő önvezető és megáll ő is (vagy kikerüli), pont az önvezetés miatt ugyanis biztonságos követési távolságot fog tartani.
A helyes program lényege, hogy lekezeli az esetlegesen felmerülő rendellenességeket. -
gforce9 #212 "ha elég jó frekvenciában jön a kocsi, akkor rosszul számolja ki a távolságot vagy időt akkor karambol az érték eltolódhat másodpercekkel, vagy méterekkel"
Mindig lesznek olyan lehetőségek, amikkel nem számolnak, de ezek jellemzően nem ezek szoktak lenni. Az általad említett probléma már programkód szintjén elhasalna (értelmesen megírt program esetén). Mert egy távolságmérésért felelős program, ami egy adott távolságot számol és az jön ki belőle, hogy az utolksó 2 mintavételezés között (ami tegyük fel 0.001mp) eltelt időben hirtelen 3m-el változott meg X számolt paraméter, azt egy jól megírt programnak kutya kötelessége kiszűrni. Folyamatosan ellenőriznie kell, hogy a számolt érték nem mond e ellen - pongyolán fogalmazva - a fizika törvényeinek. Ez a szoftveres oldal.
Hardveres oldalról a beérkező érzékelők szinkronját lehet figyelni, amiknek ugyanazt kell mutatniuk. Ha eltérés van, netán az érzékelő rendszer redudanciája a kiesett szenzorok miatt átmegy a "nem létezik" fázisba, akkor a rendszeren el kell indítani a leállási folyamatot. A tervezők eszköztárában nagyonsok olcsó megoldás van arra, hogy egy rendszer hibáját vagy rossz működését azonnal észleljék.
Ezek egy kritikus rendszer tervezésénél megkerülhetetlen alapvetések és a kutya nem is itt lesz elásva az önvezető autók terén. Azok az érzékelők jól fognak működni és a távolság számítása vagy pontos lesz vagy átadja a vezetőnek az automatika a kormányt.
A probléma akkor van egy ilyen rendszernél, ha elbizakodottan vagy pusztán anyagi okok miatt ezt a szigorú tervezési szabályrendszert nem követjük vagy olyan feladat elé állítjuk a rendszert, amire nem lett felkészítve. Sajnos ez sokszor előfordul.
Én sokkal jobban aggódom azon problémák miatt, hogy mi lesz akkor, ha az autó a saját bíróddá fog válni? Elüt egy kiszaladó gyerekcsapatot vagy ezt elkerülendő téged ütköztet inkább bele egy betonoszlopba. Ezzel nem tudom, hogyan fog megbirkózni az autóipar és a törvényhozás.
A #211-re. Igen tudom. De a hiba akkor is az apró komponensek egyrendszerben. Hibájuk kideríthető, utána javítható vagy áthidalható vagy kikerülhető. Pontosan jó írod. Van néhány logikai alapművelet és nem több. Ebből áll össze a nagy egész. -
Irasidus #211 "Én pontosan fogalmaztam. Egy program adhat hibátlan eredményt (sosem téved mondjuk 1+1=2) És adhat hibás eredményt. (1+1=3)"
Itt a probléma a gondolatmenettel! Egy önvezető autó, nem két szám összeadásából áll, itt nagy komplexitású szoftverekről van szó, ahol a programok egymásba ágyazódnak, meghívják egymást, és nem matematikai logikát követnek. Annyira bonyolult a rendszer, a sok "és", "vagy", "ha", "kizáró vagy", stb.-től, amik sokszorosan egymásba épülnek, hogy az a kettő meg kettő, sok esetben négy, és néhány esetben meg nem négy. És most csak a legegyszerűbb variációt mondtam el, arról nem is beszélve amikor már a firmware vagy hardwer is bejátszik a képbe. Vagy a generikus algoritmusokról nem szólva, amikor fogalmad sincs mi lesz a végeredmény. Na, jó nem folytatom, szerintem érthető.
Utoljára szerkesztette: Irasidus, 2017.12.14. 19:50:26 -
Irasidus #210 A szoftver nem matematikai alapokon készül, hanem formális követelményspecifikáció alapján. Ami azt jelenti, hogy egy adott dolgot meg lehet csinálni többféleképpen, nincs egyenesen kikövezett út egy programhoz. Így meg lehet csinálni ezer oldalban is, és kettőben is, többféle algoritmust is használhatsz egy adott problémára. Ezt formális módszereknek hívják. A hibák alatt nem féletlenül azt értjük, hogy hibás a program, hanem egy adott feladatra esetleg rossz követelményspecifikációt választottak, de maga a program lehet matematikailag kiváló, és hibátlan. Viszont én nem erre gondoltam. Van ennek egy fordítottja is, mikor hibás a program, de maga a program funkcionálisan helyes. Viszont, van úgy, hogy maga a rendszer nem engedi, hogy funkcionálisan helyes programot csinálj, mert nem lehet véletlen számot generálni, nem lehet egy bizonyos számnál nagyobbat az integerben meghívni, vagy nem lehet egy bizonyos törteket eltárolni, számolni velük. Ilyenkor, hogy a program működjön más, nem matematikai módszereket kell alkalmazni. Szóval a program jó, csak éppen matematikailag 2+2 nem 4 lesz benne, hanem 5. Viszont, én nem erről beszéltem, hanem arról, hogy nincs hibátlanul működő program, felsoroltam legalább vagy 5-6 problémát amik program helyes működését, így vagy úgy akadályozzák. Ezért sincs sehol a világon olyan rendszer, ahol kizárólag számítógépre bíznának emberi életeket, emberi felügyelet nélkül. Itt azt akarják megtenni, ami veszélyes, és kiszámíthatatlan.
Kérdésedre a válasz az, hogy nem. Ennek neve is van, tickelésnek hívják. Példának okáért a ha egy másik autót kell követnie, és mérés során olyan törtszám jön ki, amit bináris módon nehéz eltárolni (mert irracionális szám), ha elég jó frekvenciában jön a kocsi, akkor rosszul számolja ki a távolságot vagy időt akkor karambol az érték eltolódhat másodpercekkel, vagy méterekkel. Nyilván ezt lehet kezelni, de millió ilyen probléma van, ne tőlem várjátok a megoldást.
Utoljára szerkesztette: Irasidus, 2017.12.14. 19:33:23 -
gforce9 #209 Amúgy már ebbe a pici példába is irtózatosan sok hiba képződhet, de hát a mérnök és szoftverfejlesztő közös feladata, hogy a hibák lehetőségét a 0 felé tolják. Hátlátlan meló, a munkám felét jelenleg célhardver tesztelés adja és lényegében rohangálok a mérnök és a szoftverfejlesztő között, mikor ki a ludas :) -
gforce9 #208 Én pontosan fogalmaztam. Egy program adhat hibátlan eredményt (sosem téved mondjuk 1+1=2) És adhat hibás eredményt. (1+1=3)
A program mindkét esetben hibátlanul fut le. Sosem hibáznak.
A fenti példánaál tegyük fel, hogy adott két érzékelő, ami érzékel és 0.1V-0.5V között 0 az érték 0.8Vés1.2V között 1. A két érzékelő outputja az algoritmusunk inputja. A kimenet pedig vagy 0 vagy 1 vagy 2-nek kell lennie, mert összeadja a két értéket.
Kapunk egy adatot: 3 Az érték hibás. Okai lehetnek:
1. Szarul van megírva az algoritmus. (1+1, vagy 0+1 eredményét úgy számolja ki, hogy 3-nak adódik, blőd matematikai hiba van az algoritmusban)
2. Szar inputot kapott. (nem 1+1-et hanem 1+2-t vagy 1.5+1.5-öt stb.Adódhat rossz érzékelőből akár, rossz jelkonvertálásból, vagy egyéb külső okból)
3. Szar a hw amin az algoritmusunk fut (teszemfel ramhibás).
Tökmindegy melyik a hiba oka, a program ugyanúgy és hibamentesen fog lefutni. Az eredmény amit ad az lehet hibás, de ez sohasem azért, mert a program hibázik. Azért ad hibás eredményt, mert a komplett rendszerünk valahol hibás. Ez lehet mechanikai hiba, elektromos hiba vagy rosszul megírt programkód. Mindenesetre ez a környezet monitorozható és kideríthető.
Ha egy programozó azt látja, hogy a kódja rossz eredményt ad (tegyük fel a hardveres környezet hibátlan) Átnézve a kódot a logokat stb és az általa ejtett hibát meglelve fejére csap: "Hát persze hogy rossz eredményt ad! Mert itt és itt elkúrtam a számítást, ciklust vagy épp egy kurva zárójelet nem zártam le :)" -
#207
Ha végtelenszer utasítom a számítógépet egy művelet elvégzésére, akkor végtelenszer ugyanazt a végeredményt kellene kapni, ha nem randomgenerátor van a folyamatban. A számítógép nem működne, ha ez máshogy történne. Vagy rosszul tudom...? 
-
#206
Pontatlanul használja a hibázik jelentést. Szimplán arra gondol, hogy programozási hiba miatt "hibázik a program". Csak az nem hibázás, hiszen belve van kódolva a hiba (ahogy a modás is tarja), a program tökéletesen végrehatja azt, ami a kódjában van. Csak, ha a kód hibás... -
cylontoaster #205 "pontatlanság egy idő után ugye összeadódik"
Ez csak akkor igaz, ha viszi tovább a korábban kiszámolt értékeket. Tudsz erre példát egy autó esetében? Nem megméri a pillanatnyi sebességét, hanem tudja hogy mikor mennyivel gyorsult és ebből számolja ki azt?
Vagy reggel elindult a garázsból, azóta tudja mikor mennyit fordult és mekkora utakat tett meg, és ebből helyezi el magát a térképen?
Van az integernél nagyobb változó, és pontosabb is. Egyszerűen ha előre tudod, hogy mekkora pontosság kell (és itt tudod), akkor olyan változót hozol létre, ami ennek megfelelő. Mindig vannak hülyék, akik 2 litert akarnak a féldecis pohárba tölteni, de ezt elég jól ki lehet szűrni.
A mobil és a PC több ok miatt nem jó példa:
1: pont azért, amit írsz, max anyázol egyet és ennyi, egyszerűen egy szintnél jobban nem éri meg a fejlesztőknek tesztelni, mert több pénzt égetnek el a tesztelésre, mint amennyi elmegy arra, hogy valaki közli hogy bugos fos, és mást vesz. Egy önvezető autónál ez nyilván tök más, ahol életek múlnak a programon és probléma esetén bedőlhet a cég.
2: ezek mind összetett rendszerek, amiket telepakolsz third-party cuccokkal. Ezeket is lekezelhetné az OS helyesen, csak sokkal nehezebben. (Holnapra viszek egy állatot, építs neki "tárolót" ahol életben marad, de meg sem szökik. Persze nem mondom meg milyen állat).
Ezen felül milyen hibákat csinál az OS-ed? Tönkrevágja a vinyót, vagy más alkatrészt? Nem, mert ezeket helyesen lekezeli, ugyanis ezek nem felvállalt kockázatok. Az hogy néha összeomlik a böngésző, az belefér. Az hogy az autó rossz irányba megy, az nem fér bele, az hogy néha félreáll mert hibát talált, az igen.
És nem, a program nem hibázik. Ha azonos bemeneteket kap, akkor azonosan fog válaszolni, édesmindegy mennyiszer futtatod. Az lehet, hogy te megnyitod 600x a böngészőt, és ettől 5x elszáll, és te azt hiszed, hogy 600x ugyanazt csinálta.
Eredetileg ezt írtad: "és akkor abból a típusú autóból százezer ment a fának -egyszerre."
Ezt utólag persze kényelmes arra cserélni, hogy soha nem lesz 100%-osan megbízható az önvezető autó, de a vita ettől még nem ez. Soha nem lesz a közlekedési lámpa sem ennyire megbízható, a vasúti átkelőknél elő is fordul néha. Soha nem lesz tökéletesen megbízható a fék vagy a kerék sem, ahogy az útminőség sem. -
Irasidus #204 Te írtad: " Hibátlan rendszer nincs és nem is lesz, ebben egyetértünk. Amiben nem értünk egyet az az, hogy a "program hibázik" Nem hibázik az semmit. Az lefut, pontosan úgy ahogy megírták." miközben azt írod, hogy
"Az objektum orientált programozás korában egy érzékelőből értéket kiolvasó és azt továbbító programrész (illetőleg objektum) hibátlanul és tökéletesen fog működni amíg a környezet adott "
Korábban :
Én: "... de tökéletesen futó , vagy ideálisan futó program nincs!"
Te: " Ne haragudj, de van."
Kicsit ellentmondásos vagy...
Utoljára szerkesztette: Irasidus, 2017.12.14. 17:07:43 -
Irasidus #203 Pedig a program hibázik, minden percben számítási hibákat vét - programozástól függetlenül, leírtam mi az oka. Ezt vagy elfogadod, vagy nem, de utána is nézhetsz, hogy miről beszélek, vagy linkelhetek is. Te döntesz! Viszont ez még mindig struccpolitika a részedről. Az ilyen programokat nem egy ember írja, hanem több tucat vagy inkább száz, amit egyetlen ember sem képes átlátni, így hibák ebből adódóan is óhatatlanul lesznek. Egy dolgot lehet tenni, addig tesztelni, amíg nincs hiba. De ez valójában nem azt jelenti, hogy nincs hiba, csak azt, hogy a tesztek során nem jött elő, mert ott vannak, valahol, amíg egyszer csak valamit nem okoz. Ez lehet egy bagatel dolog, de lehet egy rendszerösszeomlás is. Egy olyan eszköz esetében, amin az életem múlik, a bagetel dolog is lehet halálos. Nos, én ezt nem szeretném.
"A z objektum orientált programozás korában egy érzékelőből értéket kiolvasó és azt továbbító programrész (illetőleg objektum) hibátlanul és tökéletesen fog működni amíg a környezet adott (hibátlan hw, kábelezés, érzékelő, stb.). "
Hibátlan és tökéletes eszköz meg nem létezik! De ha ennyire kötöd az ebet a karóhoz, kérlek mondj egy összetett programot, ami tökéletes, hibátlan! Köszi.