Ihr Gamer und Physiker, ich fordere euch heraus!

@Noumenon

Noumenon schrieb:Und genau darauf wollte ich doch hinaus!

Ich widerspreche dir in diesem Punkt ja auch gar nicht.

Noumenon schrieb:Und diese Frage lässt sich so nicht beantworten, weder mit Verweis auf die Realität, noch mit Verweis auf irgendeine "Logik"...

Das ist richtig.
Die Argumentation "Ich kann Mammutbäume mit meinem Jeap platt machen also schaffe ich auch strassen laternen."
Ist nicht logisch sondern intuitiv.

Allerdings die meisten meinen Computerspiele sollten Intuitiv sein.
Der Grund ist dass der Spieler irgendeine nachvollziebaren zusammenhang zwischen seinen Aktionen und den Reaktionen des Programmes sehen will. Damit er ein Gefühl von Kontrolle hat.
Der Spieler schaut sich den Source code des Programmes in der Regel nicht an.
Die Logik des Programmes bleibt ihm also verborgen
Der Zusammenhang ist also intuitiv...oder oft nicht nachvollziehbar.

Kommen wir zu den Portalen:
Was die Portale im Spiel tut....nun ja Versuch macht klug. ausprobieren.
Ich werde mir das Spiel offensichtlich nicht dafür kaufen

Was sie tun sollten...Ich habe oben eine Formel aufgeschrieben was sie tun sollten...

JPhys2 schrieb:Sei R die Rotationsmatrix die die Koordinatensysteme der beiden Portale verbindet
Sei Va die Anfangsgeschwindigkeit der Box
Sei V1 die Geschwindigkeit des Eintrittsportals
Sei V2 die Geschwindigkeit des Austrittsportals
Sei V end die Endgeschwindigkeit

Dann ist
V-V2=R(Va-V_1 )

Wie gesagt basierend auf der Annahme dass sie das simulieren sollen was wir in hunderten von Fantasy Filmen und Büchern von Portalen zu erwarten gelernt haben.....

Nicht basierend auf logischer Notwendigkeit. Und ganz sicher nicht basierend auf irgendwelchen Physikalischen Gesetzen

@JPhys2

JPhys2 schrieb:1)Ich sehe darüber hinweg dass du deine Variablen nicht dekarierst
Aber return z sollte man wirklich nicht vergessen.
Was der Rückgabe Wert der Funktion ist gehört nun wirklich zur logik..

Nö, ob eine Rückgabe per 'return' nötig ist, hängt von der jeweiligen Programmiersprache ab.

JPhys2 schrieb:2)Damit liest sich deine obige Rechng aus
7=Summe(2,3)=Summe(Summe(1,1),3) und weiter geht es so auch nicht...

Achso, ja, verstehe, was du meinst. :)

Ja, es ist natürlich keine zulässige Äquivalenzumformung (Assoziativität). Und der Compiler würde bei einer Abfrage nach Wertgleichheit von summe(summe(1,1),3) und summe(1,summe(1,3)) auch false ausspucken, denn in einem Fall ist das Ergebnis 7 und im anderen Fall 5, aber genau darum ging es mir ja. Wäre meine Funktion korrekt implementiert (ohne den eingebauten Rechenfehler), hätte der Compiler hier Wertgleichheit anzeigen müssen.

Aber du hast recht. Das war vllt. etwas unsauber ausformuliert...

JPhys2 schrieb:Und (1+1)+3=1+(3+1) gilt nicht wenn man "+" als deine Funktion auffasst
Also hast du mitten in der gleichungskette die bedetung von"+" geändert
Als Mathmatiker solltest du in der Lage sein das festzustellen...

Zumindest weiß ich, dass derartige Fehler in der Eile des Gefechts selbst so manchem Prof noch unterlaufen...

Aber gut aufgepasst. Dann können wir ja mit der Vorlesung endlich weitermachen. :D

JPhys2 schrieb:Warum sollte
(1+1)+3 =1+(3+1)
gelten wenn dein + nicht assoziativ ist?

Gilt aufgrund meines eingebauten Rechenfehlers natürlich nicht, nein. Die Assoziatität gilt natürlich schon aus anderen Gründen bzw. Beschränkungen von Ganzzahl-Datentypen (Stichwort 'overflow', etwa) nicht, aber darum ging es wie gesagt nicht wirklich.

JPhys2 schrieb:Du könntest die Funktione Summe auch
als
function Summe(a,b){return a mal b } definieren

Das stimmt. Aber nach ein paar Probeläufen wird jeder halbwegs schlaue Anwender bzw. Programmierer feststellen, dass hier gar nicht addiert, sondern multipliziert wird und entsprechend auch Vorhersagen für andere Fälle treffen ("Wenn ich die Funktion jetzt mal mit den Werten 2 und 4 aufrufe, kommt als Rückgabewert bestimmt 8 zurück, und nicht 6...").

JPhys2 schrieb:Der Name ist schreckich unintuitiv

Der Name suggeriert etwas, was nicht unbedingt der Fall sein muss. Wenn du die Funktion 'Summe' nennst, in Wirklichkeit aber immer ein Produkt zweier Zahlen bekommst, sollte man sich bei der Vorhersage, was die Funktion bei zwei ganz bestimmten Zahlen x und y macht, also nicht vom Namen verleiten lassen...

Mir ging's nun aber darum, dass sich auch aus dem Verhalten der Funktion (spuckt bspw. jedes Mal die Summe zweier eingegebener Zahlen aus) keine Vorhersagen für andere Fälle ableiten lassen. Deshalb mein Beispiel mit einer Funktion die - unabhängig davon, wie sie nun heißt - in fast allen Fällen die korrekte Summe zweier Zahlen liefert, in einem konkreten Fall (2 und 3) jedoch nicht. So wie ich @mathematiker verstanden hatte, glaubte er nun bspw., bei Portal eine gewisse "Spiellogik" zu erkennen, aus der sich dann das Verhalten des Würfels in dem eingangs darlegten Szenario ableiten ließe. Genau das ist aber nicht der Fall. Man kann dieses Szenario nur nachbauen (bspw. per Leveleditor) und gucken, was passiert. That's it.

JPhys2 schrieb:Nicht basierend auf logischer Notwendigkeit. Und ganz sicher nicht basierend auf irgendwelchen Physikalischen Gesetzen

Genau...

@Noumenon

Noumenon schrieb:Nö, ob eine Rückgabe per 'return' nötig ist, hängt von der jeweiligen Programmiersprache ab.

Es muss ja kein Return sein. Aber irgendwie muss man der Funktion schon sagen was der Rückgabewert sein soll...
Hast du eine Programiersprache gefunden in der der Rückgabewert immer z heisst ?
Oder vielleicht das letzte abgearbeitete ist gleich Zeichen den Rückgabewert der Funktion angibt?
Hypothetisch möglich ist das natürlich...aber ehrlich ich glaube nicht dass das eine Gute Idee ist.

Nun ja wir müssen das auch nicht wirklich ausdiskuteren...so wichtig ist mir der Punkt nicht

Noumenon schrieb:Achso, ja, verstehe, was du meinst.

Gut das wir das geklährt haben.

Noumenon schrieb:Zumindest weiß ich, dass derartige Fehler in der Eile des Gefechts selbst so manchem Prof noch unterlaufen...

Sicher Jeder macht Fehler.

, glaubte er nun bspw., bei Portal eine gewisse "Spiellogik" zu erkennen, aus der sich dann das Verhalten des Würfels in dem eingangs darlegten Szenario ableiten ließe. Genau das ist aber nicht der Fall.

Die ganze Wissenschaft beruht auf der Annahme dass du aus strukturen in den beobachtungen aus der Vergangenheit auf Ereignisse in der Zukunft schliessen kannst
Das gleiche Prinzip kann man auf Computer Programme anwenden.

Man hat im Fall des Computerprogramms den Vorteil dass man indem fall weiss dass es einen inteligenten Designer gibt.Auf der Plus seite:
Man weiss dass das Programm Gesetzen gehorcht. Und man weiss dass die Gesetze im prinzip von einem Menschen nachvollziehbar sind, was nicht heissen muss dass die Bedienung des Programmes einem eine faire chance geben müsste das zu tun.
Aber im Fall des Universums kann es schlicht sein dass die "wahren Naturgesetze " falls es sowas denn gibt. Die intellektuelle Aufnahme fähikeit eines Menschen so übersteigen wie Quatentfeldtheorie die einer Ameise übersteigt.
Zusätzlich wollen die meisten Programmierer dass der User ihre Programme versteht.

Ich würde sagen...die Bedingungen für den Einsatz von Empirik sind um feszustellen was Computerprogramme tun mindestens so gut wie in der realen Welt.

Natürlich bietet das alles keine Garantie dass kein Scherzbold ein Programm geschrieben hat dass am 29 Februar etwas völlig anderes tut...

@JPhys2

JPhys2 schrieb:Es muss ja kein Return sein. Aber irgendwie muss man der Funktion schon sagen was der Rückgabewert sein soll...
Hast du eine Programiersprache gefunden in der der Rückgabewert immer z heisst ?
Oder vielleicht das letzte abgearbeitete ist gleich Zeichen den Rückgabewert der Funktion angibt?
Hypothetisch möglich ist das natürlich...aber ehrlich ich glaube nicht dass das eine Gute Idee ist.

Schon einmal mit MATLAB gearbeitet...?

JPhys2 schrieb:Die ganze Wissenschaft beruht auf der Annahme dass du aus strukturen in den beobachtungen aus der Vergangenheit auf Ereignisse in der Zukunft schliessen kannst
Das gleiche Prinzip kann man auf Computer Programme anwenden.

Genau das ja eben nicht, wie's bspw. eindrucksvoll durch das Testvideo demonstriert wird. Einzig die Entwickler selbst hätten dieses Verhalten vorhersagen können - klar, sie kennen ja auch den Quellcode usf.

JPhys2 schrieb:Ich würde sagen...die Bedingungen für den Einsatz von Empirik sind um feszustellen was Computerprogramme tun mindestens so gut wie in der realen Welt.

Äh, ja, wenn man empirisch überprüft, was das Computerprogramm genau macht, dann weiß man, was das Computerprogramm macht... sehr schlau. Hier ging es aber darum, aus empirischen Beobachtungen eine "Spiellogik" abzuleiten und auf den eingangs geschilderten Versuchsaufbau anzuwenden, was nun einmal Unfug ist.

@DeadPoet

DeadPoet schrieb:Wenn man clever ist, kann man natürlich irgendeine "Portalenergie" hinzunehmen, die letztlich aber fiktiv ist. Für mich stellt sich das so dar: Das Portal von oben fällt wie ein Hoolahoop-Reifen über den Würfel. Sobald der Reifen unter die Oberkante des Würfels gefallen ist, liegt der Würfel schon zu einem Teil auf der "anderen Seite". Dort wirkt die Erdanziehungskraft von einer anderen Seite, so dass der Würfel zur Seite fällt. *plopp* Das wars.

Das Problem ist ja das es bei allen Versionen ein Energieproblem gibt. Was du vergisst ist das der "Hoolahoop-Reifen" den Würfel nicht "Beamt" sondern eigentlich nur ein Durchgang darstellt. Irgendwie muss die Bewegung des Würfels aber zustande kommen ob a) oder b) ansonsten hast du in beiden Fällen ein Paradoxon, mit Gravitation alleine lässt sich die Bewegung des Portals nie und nimmer kompensieren ;)

...aber eigentlich müsste man erst mal wissen ob solche Portale in der Realität überhaupt existieren könnten damit würde sich auch diese Diskussion hier erledigen. ;)

@JPhys2
Man, mir ist schon wieder ein Fehler unterlaufen! *facepalm*

Du hast natürlich recht:

JPhys2 schrieb:Es muss ja kein Return sein. Aber irgendwie muss man der Funktion schon sagen was der Rückgabewert sein soll...

Deshalb würde meine Funktionendefinition so nicht funktionieren (auch bei Matlab nicht). Ich dachte eigtl., ich hätte es auch so wie nachfolgend geschrieben, hatte ich wohl aber doch nicht (scheiß 'false memory'). Nun ist's korrekt:

(bei MATLAB allerdings ohne 'then')