Inverz.. Ha a bal tenyeredet közelíted a jobb tenyeredhez, akkor
mint minden relatív mozgás esetében, most is érvényes az inverzének tükörszimmetriája.. azaz a mozgással, a közelítéssel egyben a bal tenyeredhez közelíted a jobb tenyeredet.
Nem létezik, nem is létezhet olyan relatív mozgás, amely aszimmetrikus lehetne.
Ez a relativitás, a viszonyítás fogalmából következik.
A nagyobb a kisebbhez képest nagyobb, és s kisebb a nagyobbhoz képest kisebb..
és sorokhatnánk.
Két test, rendszer egymáshoz képesti mozgásnak egyetlen sebessége van.
Így nem csak a mozgást végző inverz, hanem a mozgás sebessége is iránya is az.
Ha egy mozgásnak nem inverze a másik rendszerbeli megjelenése, akkor téves
a függvényfelvétel.
Így a fénygömb középpontjában lévő pontot gömb alakban veszi körbe a fény.
A fénygömböt és középpontját az őt alkotó fotonok határozzák meg, így az a test aminek térbeli helye nem esik egybe ezen középpontal, az nincs a fénygömb középpontjában.
Ami pedig nincs a középpontban, azt nem is veheti gömb alakban körbe a fénygömb!
"de érdekelne, hogy miért rossz módszer [az önmódosító kód]"
két okból:
1. biztonsági ok. egy rossz mozdulattal felülcsapja az ember a kódot, és aztán csak az isten tudja, hogy a program mit csinál, beleértve a hardvert károsító rosszalkodásokat. ez inkább a régi indok.
2. olvashatóság. ez a mai fő ok. legyen a program bár tízszer lassabb, kétszer akkora, de legyen áttekinthető. a hardver olcsó, a programozó drága (és még hibázik is a dög).
"Az MM kisérlet hasznavehetetlenségéről volt szó."
itt te vagy az, aki nem tudja követni, miről van szó. az MM kísérlet cáfolja az éterszél létezését. ez neki a haszna.
nyilván nem tudja megválaszolni, hogy akkor hogyan terjed a fény, csak azt tudja, hogy úgy biztos nem, ahogy azelőtt gondolták.
az MM kísérlet, és az összes többi kísérlet további haszna, hogy mintegy sarokpontokat jelöl ki, hogy milyen elméleteket lehet elfogadni. az elméletek jönnek-mennek, de a kísérlet örök, és minden jövőbeli elméletnek meg kell felelnie a kísérletek eredményének.
persze itt van az astrojan féle megoldás: csinálunk egy elméletnek látszó tárgyat, ami ellentmond az MM kísérletnek, majd az MM kísérletet letagadjuk hazudozással.
Érdekes. Pedig sok interpreteres programnyelvben lézeznek az ú.n. makrók is, amelyek adatként megadott programutasítások. És ha a LISP nem is ilyen, az Omnis nevű programról biztosan tudom, hogy a változókat és a forráskódot olyannyira egyformán adatként kezeli, hogy teljesen szabályos dolog benne egy procedura futás közbeni megírása, majd lefuttatása. Ennek mondjuk az a kényelmetlen következménye van, hogy nem lehet megállapítani két adott, Omnisban írt programfile-ról, hogy azonosak, vagy különbözők, mivel a fájlok minden futtatáskor mindenképpen megváltoznak. Akkor is, ha explicit programváltoztatásokat nem tartalmaz a megírt kód. Ez speciel tényleg hátrány, de valami előnye csak van ennek a módszernek is, ha már egyszer kitalálták, és meg is valósították.
(elnézész az offért, ha érdekel mást is ez a kérdés, és tudtok jobb helyet a megvitatására, folytassuk ezt ott.)
Már tegnap is válaszolni akartam erre, de aztán valahogy elmaradt.
Csak egyetlen kérdés a reakcióm: szerinted számít, hogy az autón van a lámpa vagy a kereszteződésben áll? (feltételezve azt, hogy egyébként mindkét esetben ugyanott és ugyanabban a pillanatban villan a lámpa)
Hát lényegében azért, mert teljes mértékben követhetetlen, hogy mit csinál egy ilyen program. Ezért többnyire a "barátságtalan" programok csinálnak ilyet, hogy nehezebb legyen elkapni "őket".
"Alakul már, de ne felejtsük ki az indexelést. Azt is mondhatjuk, hogy a forgatás előtt t2-t1-től függ a minta, a forgatás után pedig t1'-t2'-től,.."
Már nem azért, de ha egyszer megegyezünk, hogy a t1-t2-től függ a minta, akkor forgatás közben is ugyanettől függ: t1'-t2'-től. És mivel tudjuk, hogy épp 90 fokos elforgatásnál t1'=t2 és t2'=t1 ezért bátorkodtam felírni, hogy a forgatás után t2-t1-től függ a minta
A te általad írtakban rendkívül könnyű megtalálni a hibát: ne használd ki, hogy éppen 90 fokkal forgattuk el, legyen ez valami tetszőleges elforgatás, és írd fel, hogy eredetileg milyen értéktől függ a minta és utána milyen értéktől függ a minta.
Foleg azert, mert mar nagyon egyszeru "onmodositasok" is kiszamithatatlan kovetkezmenyeket okozhatnak, azaz az onmodositas kezelhetetlen. A LISP sem ilyen.
az ősi programokban sem számított szép megoldásnak, ha a program magát módosítja, vagy pedig egyes részei néha adatként, néha kódként funkcionálnak. hovatovább ez egy ROSSZ módszer, kerülendő
Sajnos nem nagyon értek a programozáshoz, és offtopik is a dolog, de érdekelne, hogy miért rossz módszer ez. Az ember azt hinné, hogy nincs rugalmasabb dolog, mint egy önmagát módosító program. A LISP nyelv nem ilyen például?
Igazából nem tudom hogyan lehetne kiszámolni, hogy mennyivel mozdul el a csíkozat, hiszen nem is tudom hogyan mérhetnénk, a csíkozás elmozdulását.
Itt a fő probléma, fogadok, hogy senki sem tudja, nem is tudhatja mert az egész elképzelés hibás. A futásidő különbségeken alapuló okoskodás csalóka, pontosan ezért amit mondasz. Senki sem tudja merre kellene mozdulni a csíkoknak a jobbra vagy a balra forgatáskor. Az egyetlen ésszerű magyarázat: semerre.
De az jól látszik, hogy a forgatás előtt t1-t2-től függ a minta, a forgatás után pedig t2-t1-től,..
Alakul már, de ne felejtsük ki az indexelést. Azt is mondhatjuk, hogy a forgatás előtt t2-t1-től függ a minta, a forgatás után pedig t1'-t2'-től,..
tehát a két érték különböző,
A két érték nem különböző, pontosan, hogy azonos, hatvanszor leírtam már
t1-t2 = t2'-t1'
valamint ez is igaz
t2-t1 = t1'-t2'
hihetetlen ha nem fogod fel, így persze érthető ha az én képességeimet kérdőjelezitek meg. Az az egyenlőségjel a két kifejezés között azt jelenti, hogy nem különböző, hanem egyenlő.
Ez nem ilyen egyszerű. Turing nagyon is gyakorlatias ember volt. Pl. miután 1939-ben Princetonból hazatért Cambridge-be, mechanikus számítógépet tervezett a Riemann-zeta gyökeinek számítására (ugyanis nem hitt a Riemann-sejtésben, ellenpéldát igyekezett találni). Nem csak precízen megtervezte a 80 fogaskerékből álló szerkezetet (amely az árapály-jósló gépek egy variánsa volt), hanem 40 fontos grantot is igényelt az angol Royal Society-től az elkészítésére, majd miután a pénzt elnyerte, saját kezüleg elkezdte kiesztergálni a kerekeket. Azonban a háború félbeszakította ezt a munkát, ő pedig szellemi energiáival beszállt a hadviselésbe. Neumann Princetonban ismerte meg Turing-ot, és olyannyira elismerte őt, hogy az IAS-ben akarta tartani asszisztenseként. De Turing hazautazott, Neumann pedig az ENIAC tervezésébe bekapcsolódott. Ha Turing Princetonban maradt volna, ma talán Turing-elvként emlegetnénk a Neumann-elvet. Ne érts félre, Neumannt óriásnak tartom, de itt az igazi érdem Turingé szerintem. És azt se felejtsük el, hogy a Turing-gép sok évvel megelőzte az elektronikus számítógépet, és itt sem tudok nem ok-okozati kapcsolatot látni.
ezeket már megbeszéltük. én úgy szoktam, hogy rányomok a válasz linkre, de shift-ctrl párossal, ez nálam a háttérben nyitja meg (opera). aztán tovább olvasom, és ha látom, hogy a mondandóm már nem aktuális, lezárom a válaszablakot.
na de itt van ez a mondat:
"Azonkívül a program és adat nem olyan élesen válik ketté ahogyan móriczka elképzeli."
Kedves pint, a Neumann elvet is légyszives azon dolgok közé rakri amit nem értesz, és kérdés, hogy valaha érteni fogod-e...
"ha a program magát módosítja, vagy pedig egyes részei néha adatként, néha kódként funkcionálnak."
Nem ez az Neumann elv.
"a neumann elvet lehúzzuk a wc-n" Mennyivel "jobb" lenne nekünk a pint elven működő számítógép: minden adat hordozó két féle lenne, lennének az adatok és lennének a programok. A kódolásuk teljesen különbözne. Memóriából is kétszer annyi kéne, mert lehet, hogy az "adat" memóriában lenne hely, de a "program" memória már esetleg elfogyott.
Azonkívül a program és adat nem olyan élesen válik ketté ahogyan móriczka elképzeli.
