Hätte nicht gedacht, dass ich so etwas mal brauchen werde. Was bei allen Programmiersprachen üblich ist, da es sich hier um einen Prozessor-Befehl handelt, ist bim RPG-Maker einfach nicht eingebaut.
Meine Frage: Wie lässt sich eine bitweise XOR-Operation mit zwei Variablen simulieren? Am besten wäre, wenn jemand eine mathematische Formel posten würde, die es dafür gibt. Ich komme leider nicht darauf. Die NOT-Operation habe ich geschafft, umzusetzen, aber dieses XOR macht mir Probleme.
Dazu müsstest du die Variablen in Binärwerte umrechnen. Dazu könnte man jetzt eine Variable "Binär" erstellen und diese dann etwa den Wert 100101 geben. Das Problem ist, bei 6 Stellen ist für den Maker Schluss und damit kommt man nicht so weit. Also bräuchtest du schon mindestens 2 Variablen um den Binärwert darzustellen. Dann musst du den Wert jeder Ziffer abfragen und diesen mit dem Vergleichsbit vergleichen. XOR müsste doch so aussehen:
Nach diesem Schema also dann entscheiden ob das Ergebnis wahr oder falsch, 1 oder 0 ist.
@Ynnus:
Naja, meine Variablen nehmen 5-stellige Werte an und die umzurechnen wären eine heidenarbeit. Ausserdem verwende ich ja gerade Variablen, um grosse "Switch"-Mengen zu simulieren. Aber dazu bräuchte ich auch die entsprechenden Operationen. Es wird doch wohl mathematische Formeln hierfür geben?
Naja, es gibt mathematische Formeln um Zahlen in Binärwerte umzurechnen. Nur dann wirst du mit Forks abfragen müssen, wie die einzelnen Stellen der Variablen aussehen usw. Leider ist der maker mathematisch alles andere als großartig und modern.
Aber wozu willst du so viele Switches simulieren, wenn ich fragen darf? Wie viele brauchst du denn? Mittels eines kleinen Hacks im Maker kann man die Obergrenze von Switches und Variablen locker auf die 30.000 hochschrauben. Ich schätze so 65536 dürften drinn sein, vielleicht auch mehr. Muss man ausprobieren. Aber mit den 30.000 ist definitiv schon getestet worden und funktioniert.
Nun, ganz einfach. Ich habe ein Schalterrätsel mit 3 mal 14 Schaltern. Jeder Schalter soll in seiner eigenen Reihe 14 Schalter zufällig an- bzw. ausschalten. Pro Schalter gäbe das also 2^14 = 16384 Möglichkeiten und dies 42 mal = 688128 Switches. Also habe ich mir gedacht, dass es mit Variablen sinnvoller wäre, da ja Zahlen nichts anderes als eine Bitfolge, d.h. eine Folge von Switches sind. Um allerdings den lösungsweg vorzuberechnen (die Schalter funktionieren nach dem Zufallsprinzip), bin ich auf bestimmte Operationen wie eben XOR oder NOT angewiesen.
BTW, um Dezimalzahlen in Binärzahlen umzurechnen, braucht man überhaupt keine Forks, sondern lediglich die / und Mod Funktionen, Zeiger-Variablen und Loops.
BTW, um Dezimalzahlen in Binärzahlen umzurechnen, braucht man überhaupt keine Forks, sondern lediglich die / und Mod Funktionen, Zeiger-Variablen und Loops.
...
Ich bezog die Abfrage mittels Forks auf das Ausfindigmachen des Ergebnisses der XOR-Verknüpfung. Und da wirst du um Forks nicht mehr herum kommen, da Bitweise Operationen nicht vorhanden sind im Maker.
Ich habe es hingekriegt, ich habe einfach ein Common Event geschrieben, dass die XOR-Funktion simuliert. Hätte eigentlich selber darauf kommen müssen, die Potenz-Funktion habe ich schliesslich auch auf die gleiche Art erzeugt. (und so etwas als Matura-Jahrgangsbester in Mathematik)
Ich schreibe mal beide Funktionen hier auf, falls sie jemand einmal gebrauchen sollte:
Die Potenz-Funktion ist Grundlage für die XOR-Funktion. Um die Funktionen im Spiel benutzen zu können, müssen folgende Befehle ausgeführt werden:
Potenz-Funktion p = b^e ausführen:
b befindet sich anschliessend in der Variable [Potenz].
XOR-Funktion z = x XOR y ausführen:
z befindet sich anschliessend in der Variable [XOR Ergebnis].
Ich habe die Codes überprüft, sie scheinen beide zu funktionieren. Falls jemand einen Fehler entdeckt hat, soll er mich bitte darauf aufmerksam machen. Verbesserungsvorschläge sind ebenfalls willkommen.
@Dhan:
Nein, so wie ich es geplant habe, geht das Rätsel gar nicht anders. Aber momentan stecke ich an einem neuen Problem im selben Rätsel, habe irgendwelche Fehler bei der Berechnung des Lösungsweges gemacht und finde sie kaum mehr.
Antworte mir doch nicht direkt ohne eine Aussage zu machen ^^
Ich hab immer noch keinen Plan, was dein Rätsel genau ist. 3 Reihen a 14 Schalter die sich irgendwie beeinflussen (was heißt "zufällig"?)... aha?
Sagt nichts darüber aus, was man in dem Rätsel eigentlich tun muss und wie genau sich die Schalter nun beeinflussen.
Ich kann dir den komplexesten Code zu irgendwelchen Schaltungen aufschreiben aber wenn ich nicht weiß, was du eigentlich brauchst, wird das nichts bringen prophezei ich mal.
Nagut, aber mal zum Thema, XOR wird bei Zeichnungen über einfache elektronische Systeme mit = 1 dargestellt. (oder mit ein paar &s, abhängig von der Eingangsanzahl)
Ums mal ganz simpel zu sagen, du splittest die Variable, die die Switches speichert, kurz mal wieder in temporäre Switches auf (also in Binärstellen) und addierst +1 zu einer neuen (ebenfalls temporären) Variable für jeden aktivierten dieser Switche. Ist die Variable = 1, so ist XOR eingetreten.
Wo liegt das Problem?
Ne aber beantworte mir bitte die Frage, was GENAU du eigentlich da baust
--
class Dog { //(...)
boolean getBuddha() { throw NullPointerException; } }
Spielt Hero-Chan!
Antworte mir doch nicht direkt ohne eine Aussage zu machen ^^
Ich hab immer noch keinen Plan, was dein Rätsel genau ist. 3 Reihen a 14 Schalter die sich irgendwie beeinflussen (was heißt "zufällig"?)... aha?
Sagt nichts darüber aus, was man in dem Rätsel eigentlich tun muss und wie genau sich die Schalter nun beeinflussen.
Ich kann dir den komplexesten Code zu irgendwelchen Schaltungen aufschreiben aber wenn ich nicht weiß, was du eigentlich brauchst, wird das nichts bringen prophezei ich mal.
...
Tja, komplexen Code schreiben kann ich auch, solange es bei Grundlagen-Programmierung bleibt.
Aber gut, ich erklär es mal:
Im Raum gibt es zunächst 14 Schalter und eine Türe. Um die Türe zu öffnen, müssen alle Schalter umgelegt sein. Sobald man einen Schalter umschaltet, werden von den restlichen 13 Schaltern zufällig vorher definierte ebenfalls umgeschaltet. Hinter der Türe kommt dann quasi dasselbe Rätsel noch einmal und hinter der nächsten gleich noch einmal. Also wenn das System für die ersten 14 Schalter funktionieren würde, wäre es kein Problem, dies umzuschreiben. Und ja, ich weiss, dass das Rätsel abartigstens, krankhaft schwierig ist, aber mein Spiel ist sowieso mehr Experiment als Spiel.
Zitat
Nagut, aber mal zum Thema, XOR wird bei Zeichnungen über einfache elektronische Systeme mit = 1 dargestellt. (oder mit ein paar &s, abhängig von der Eingangsanzahl)
Ums mal ganz simpel zu sagen, du splittest die Variable, die die Switches speichert, kurz mal wieder in temporäre Switches auf (also in Binärstellen) und addierst +1 zu einer neuen (ebenfalls temporären) Variable für jeden aktivierten dieser Switche. Ist die Variable = 1, so ist XOR eingetreten.
Wo liegt das Problem?
...
Nun, mein Code von vorhin erfüllt eigentlich den Zweck, die XOR-Funktion auszuführen. Von dem her, ist das Thema dieses Threads gelöst. Momentan habe ich ein anderes Problem.
Zitat
Ne aber beantworte mir bitte die Frage, was GENAU du eigentlich da baust
1.XOR Funktionen gehen nur bei 2 Eingängen, die abgefragt werden
2.Benutz das nächste mal direkt Wörter wir Exklusiv-Oder oder Antivalenz, damit auch jemand der nicht der Digitaltechnik mächtig ist, dir helfen kann
3.Wieso brauchst du 3*14^2 Tabs, um den Zustand von 42 Schaltern zu speichern?
4.Erklär mir bitte den Sinn deines Rätsels, da es sich eher nach einem Glücksspiel für mich anhört
2.Benutz das nächste mal direkt Wörter wir Exklusiv-Oder oder Antivalenz, damit auch jemand der nicht der Digitaltechnik mächtig ist, dir helfen kann
...
XOR kommt doch nicht nur in der Digitaltechnik vor. Ich kenne es als festen Begriff der Programmierung. Ansonsten, wer weiß was Exklusiv-Oder ist, sprich, wie man die bit verknüpfen muss um das gewünschte Ergebnis zu erzielen, der weiß auch was XOR ist. Und wer beides eben nicht weiß, der hält sich eben raus und lässt die Leute antworten, die Ahnung davon haben. So ist das eben im Forum.
1.XOR Funktionen gehen nur bei 2 Eingängen, die
3.Wieso brauchst du 3*14^2 Tabs, um den Zustand von 42 Schaltern zu speichern?
...
1. 42*2^14 bitte!
2. Ich speichere nicht den Zustand von 42 Schaltern, sondern die Wirkung der einzelnen Schalter: ein Schalter kann 14 Schalter per Zufall umschalten, demnach kann er 2^14 verschiedene Dinge tun.
Zitat
4.Erklär mir bitte den Sinn deines Rätsels, da es sich eher nach einem Glücksspiel für mich anhört
Scheinbar gehste immernoch nicht drauf ein, das eine XOR Funktion nur bei 2 Eingängen gehen.
aber nya, zu den anderen Punkten:
hä? Also du legst einen Schalter um? Soweit so klar. Dann bewegen sich mit ihm 14 weitere Schalter um, per Zufall. Richtig?
Zitat
demnach kann er 2^14 verschiedene Dinge tun.
...
demnach kann er für mich nur eine Sache tun, Zufällig umschalten, und das ist keine Sache, die man in irgendeiner Form speichern müsste. Wenn es beim nächsten Unlegen wieder alle per Zufall bewegt werden.
Achja, im Raum sind 14 Schalter, ich leg einen um und es wechseln alle anderem im Raum auch ihren Zustand. Nicht der eigentliche Schalter. Wie kommst du dann auf 2^14 möglichkeiten?
So, Ich würde das ganze mittels Variablen Regeln. Eine Variable kann imo 10^6 wertige Zahlen speichern. Damit würdest du pro Raum imo 1 Variable pro Raum benötigen. Wenn du zusätzlich auch noch die Zufällige änderung Speichern willst, brauchst du zusätzlich nochmal 1 Variable pro Raum! Wieso? Wir Rechnen einfach unser Binäres Zahlensystem und damit die Pegel unsere Schalter in unserer Wunderschönes Dezimale Zahlensystem, da wir damit Problemlos den Umgerechneten Wert von 2^14 bzw. 2^13 speichern können.
Scheinbar gehste immernoch nicht drauf ein, das eine XOR Funktion nur bei 2 Eingängen gehen.
...
Ynnus hat dazu alles gesagt. In Programmiersprachen kann man die XOR-Operation auch auf gewöhnliche Zahlen anwenden, ebenso mit dem Windows-Taschenrechner.
Zitat
aber nya, zu den anderen Punkten:
hä? Also du legst einen Schalter um? Soweit so klar. Dann bewegen sich mit ihm 14 weitere Schalter um, per Zufall. Richtig?
demnach kann er für mich nur eine Sache tun, Zufällig umschalten, und das ist keine Sache, die man in irgendeiner Form speichern müsste. Wenn es beim nächsten Unlegen wieder alle per Zufall bewegt werden.
...
Nope. Beim nächsten Umlegen schaltet er wieder exakt die gleichen Schalter um. Welche allerdings wird beim Betreten des Raumes festgelegt. D.h. sobald man den Raum verlässt, verhalten sich alle Schalter wieder anders. Und deshalb muss für jeden Schalter eine Switch-Reihe bzw. eine Variable festgelegt sein, die bestimmt, welche Schalter in dieser Sitzung umgeschaltet werden.
Zitat
Achja, im Raum sind 14 Schalter, ich leg einen um und es wechseln alle anderem im Raum auch ihren Zustand. Nicht der eigentliche Schalter. Wie kommst du dann auf 2^14 möglichkeiten?
...
Rein theoretisch wären es 2^13 Möglichkeiten. Es ergibt sich allerdings ein praktisches Problem, nämlich die Vorherberechnung des Lösungsweges. Dazu speichere ich für jeden Schalter eine Bitfolge für 14 Schalter ab mit der Anweisung, dass das Bit für den jeweiligen Schalter auf jeden Fall 1 sein muss, damit der entsprechende Schalter auf jeden Fall umgeschaltet wird.
Zitat
So, Ich würde das ganze mittels Variablen Regeln. Eine Variable kann imo 10^6 wertige Zahlen speichern. Damit würdest du pro Raum imo 1 Variable pro Raum benötigen. Wenn du zusätzlich auch noch die Zufällige änderung Speichern willst, brauchst du zusätzlich nochmal 1 Variable pro Raum! Wieso? Wir Rechnen einfach unser Binäres Zahlensystem und damit die Pegel unsere Schalter in unserer Wunderschönes Dezimale Zahlensystem, da wir damit Problemlos den Umgerechneten Wert von 2^14 bzw. 2^13 speichern können.
...
Ich brauche aber 14 Werte und nicht einen. Zudem findet alles im gleichen Raum statt, die 3 Schaltterreihen befinden sich lediglich hinter den Wänden die durch die Türen verbunden sind.
Ausserdem habe ich das Problem fast gelöst, mir fällt nur nicht ein, wie ich die Bitfolge aus der Variable, die die zur Lösung relevanten Schalter speichert rückwärts auslesen lassen soll, um die letzten beiden relevanten Schalter-Variablen-Nummern ausfindig zu machen. Diese beiden Nummern sind notwendig, um den Lösungsweg zu berechnen. Da die Bitfolge vorwärts ausgelesen wird, stimmt die Lösung im allgemeinen nicht.
jez weiß ich auch endlich was du mit dem ganzen dingel bezwecken willst,
aber weiter im Text:
Die änderung eines Schalters kannst du wiegesagt in einer Variable speichern. Indem du einmal Binär bestimmst, welche Wirkung ein Schalter hat, auf die anderen Schalter, dabei käme z.B. dieses Ergebnis heraus:
10110101011010
Um dieses Ergebnis nun Speichern zu können, müssten wir entweder 14 Switche nehmen, 3 Variablen beim 2k und 2 beim 2k3.
So, wieso Rechnen wir das ganze nun nicht einfach um, undzwar in unsere Dezimales Zahlensystem, da dort auch 11111111111111 locker in einer Variable gespeichert werden kann.
Zitat
Ausserdem habe ich das Problem fast gelöst, mir fällt nur nicht ein, wie ich die Bitfolge aus der Variable, die die zur Lösung relevanten Schalter speichert rückwärts auslesen lassen soll, um die letzten beiden relevanten Schalter-Variablen-Nummern ausfindig zu machen.
...
Meinst du jez das herausfiltern einer Stelle in eine Variable, oder die Berechnung? Wird daraus nicht so ganz klar.
jez weiß ich auch endlich was du mit dem ganzen dingel bezwecken willst,
aber weiter im Text:
Die änderung eines Schalters kannst du wiegesagt in einer Variable speichern. Indem du einmal Binär bestimmst, welche Wirkung ein Schalter hat, auf die anderen Schalter, dabei käme z.B. dieses Ergebnis heraus:
10110101011010
Um dieses Ergebnis nun Speichern zu können, müssten wir entweder 14 Switche nehmen, 3 Variablen beim 2k und 2 beim 2k3. So, wieso Rechnen wir das ganze nun nicht einfach um, undzwar in unsere Dezimales Zahlensystem, da dort auch 11111111111111 locker in einer Variable gespeichert werden kann.
...
Eine Variable kann maximal den dezimalen Wert 999999 annehmen. Wennschon bräuchte man 3 dafür, allerdings gäbe es dann ein ziemliches Problem bei der Berechnung. Ausserdem, ob ich die Werte jetzt dezimal oder binär speichere macht rein mathematisch nur den Unterschied, dass ich bei Teil- und Modulo-Operationen 10 statt 2 nehmen muss. Von dem her ist diese Methode erstens verschwenderischer und zweitens um einiges komplizierter, da man 3 Variablen braucht. Ich berechne die Variablen schliesslich mit Hilfe der Variablen-Nummern (Pseudo-Zeiger-Variante) und das wird bei 3 Variablen pro Schalter schnell undurchschaubar.
Zitat
Meinst du jez das herausfiltern einer Stelle in eine Variable, oder die Berechnung? Wird daraus nicht so ganz klar.
...
Also die Berechnung wird es wohl nicht sein, wenn ich schon in der Lage bin, Variablen binär aufzubauen und wieder zu entziffern (wird auch beim XOR-Code angewandt). Das Problem ist, dass ich die Variable in der umgekehrten Reihenfolge entziffern muss, wie sie aufgebaut ist, da ich die "Stellen" (das wären dann die entsprechenden Variablen-Nummern, die in Pseudo-Zeiger-Variablen gespeichert werden) der letzten beiden 1-Werte der Variablen, welche die relevanten Schalter speichert (ist eine notwendige Zusatzvariable, die aber nach dem gleichen Prinzip funktioniert) brauche.
Ein möglicher Lösungsansatz wäre natürlich eine Spiegelung des Bitmusters, die Frage ist jetzt wieder, wie das umzusetzen wäre. Ich könnte natürlich die Bits auslesen und nach dem Lifo-Prinzip abspeichern und wiederverwenden. Jetzt wäre eine Stack-Datenstruktur praktisch, aber eben...
Ich werde für zukünftige Spiele wohl so bald wie möglich auf den Game Maker umsteigen, die GML dort ist um einiges vielseitiger als das Event-Command-System.