Jep. Aber das ist es bis jetzt eigentlich bei keiner Rechnung die hier in den Raum geworfen wurde.
Aber das ist ja gerade das gewollte
Jep. Aber das ist es bis jetzt eigentlich bei keiner Rechnung die hier in den Raum geworfen wurde.
Aber das ist ja gerade das gewollte
Wenn mich meine alten Mathekenntnisse nicht im Stich lassen ist die Chance das man die selben Steamzahlen hat 1/10000 (1/10^4). Also bei 16000 Ids. Kann man davon ausgehen das wahrscheinlich 1,6 gerundet 2 Mal die Selbe vorkommt. Das bei diesen die Zufallszahl identisch ist liegt bei 1/100. Also insgesamt 1 zu 1 Million. Wahrscheinlicher als im Lotto zu gewinnen
Wenn mich meine alten Mathekenntnisse nicht im Stich lassen ist die Chance das man die selben Steamzahlen hat 1/10000 (1/10^4). Also bei 16000 Ids. Kann man davon ausgehen das wahrscheinlich 1,6 gerundet 2 Mal die Selbe vorkommt. Das bei diesen die Zufallszahl identisch ist liegt bei 1/100. Also insgesamt 1 zu 1 Million. Wahrscheinlicher als im Lotto zu gewinnen
Aber wenn von 1.000.000 IDs zwei dabei sind die gleich sind... ist das doch nicht schlimm.
P4sca1 Und was wäre wenn man alle vergebenen IDs in ein File schreibt und einfach immer aus diesem abfragt ob die ID enthalten ist??
Total inperformant.
Theoretisch kann man auch einfach nur vierstellige IDs nehmen und bei 2 chars einfach einfach die gleiche da die eh nie zur gleichen zeit auf den server sein werden
Die Zuweisung einer ID erfolgt ja nur bei dem Erstellen des Charakters.
Also müsste auch nur dann ein Durchlauf durch eine eventuelle Datenbank stattfinden
Aber wenn von 1.000.000 IDs zwei dabei sind die gleich sind... ist das doch nicht schlimm.
Theoretisch kann man auch einfach nur vierstellige IDs nehmen und bei 2 chars einfach einfach die gleiche da die eh nie zur gleichen zeit auf den server sein werden
Backburn hat mich drauf gebracht das bei deiner Methode Julian | Snow die Chance bei 2 Chars des Selben spielers bei 1/99 liegt weil die Steam ID natürlich gleich ist
Oder Man schaut sich an wo die ersten vier bzw fünf Buchstaben des Namens im Alphabet sind.Dafür musste man halt doppelte Namen unterbinden und ein.das es mindestens 5 oder 6 buchstaben.im namen sein muss
Backburn hat mich drauf gebracht das bei deiner Methode Julian | Snow die Chance bei 2 Chars des Selben spielers bei 1/99 liegt weil die Steam ID natürlich gleich ist
Ja, das ist so.
Das wäre aber unwahrscheinlich.
Und selbst wenn das passieren würde, wäre das nicht so schlimm.
Sollte das doch ein Problem sein, kann man ja eine Regel einführen, dass wenn beim Char erstellen eine ID rauskommt, die man schon mit einem anderen Char nutzt, man den Charakter löschen und neu erstellen muss.
LG: Julian
Oder Man schaut sich an wo die ersten vier bzw fünf Buchstaben des Namens im Alphabet sind.Dafür musste man halt doppelte Namen unterbinden und ein.das es mindestens 5 oder 6 buchstaben.im namen sein muss
Problem ist bei Eventchars und co wo ja z.b. ein Darth Maul öfters da sein kann weil ein alter Char nicht gelöscht wurde, oder ein Commander oder Lore Char
Oder Man schaut sich an wo die ersten vier bzw fünf Buchstaben des Namens im Alphabet sind.Dafür musste man halt doppelte Namen unterbinden und ein.das es mindestens 5 oder 6 buchstaben.im namen sein muss
kann man machen ist aber blöd zB Echo hat nur 4 und CMD Jet nur 3
kann man machen ist aber blöd zB Echo hat nur 4 und CMD Jet nur 3
Lore Chars würden natürlich ihre Lore ID behalten!
Allerdings hast du Recht, das ist blöd. Mein Standardname Snow hat auch nur 4 Buchstaben.
Problem ist bei Eventchars und co wo ja z.b. ein Darth Maul öfters da sein kann weil ein alter Char nicht gelöscht wurde, oder ein Commander oder Lore Char
Man könnte theorotisch auch wenn es ein.haufen arbeit wär ne Extra fraktion/Auswahlmenü für Lore Chars /commander ist mir nur grade in den Sinn gekommen.
Problem ist bei Eventchars und co wo ja z.b. ein Darth Maul öfters da sein kann weil ein alter Char nicht gelöscht wurde, oder ein Commander oder Lore Char
hättest du den Anfang des Threads gelesen wüsstest du dass man bei Eventchars einzelnen Rängen oder auch Lore-Chars die ID abschalten kann. Die müssten sich das halt binden
Dafür musste man halt doppelte Namen unterbinden
hättest du den Anfang des Threads gelesen wüsstest du dass man bei Eventchars einzelnen Rängen oder auch Lore-Chars die ID abschalten kann. Die müssten sich das halt binden
Ich habe den Thread sehr wohl gelesen, aber meines Wissens nach können diese Lore Chars wenn deren ID gesetzt wurde ihre ID auch per /id vorzeigen und Das war auch auf die Doppelten Namen bezogen, also das Zitat was hier drin ist
Ich habe den Thread sehr wohl gelesen, aber meines Wissens nach können diese Lore Chars wenn deren ID gesetzt wurde ihre ID auch per /id vorzeigen und Das war auch auf die Doppelten Namen bezogen, also das Zitat was hier drin ist
ich meinte Eventchars haben keine ID Außerdem kann man Lore-Chars nicht doppelbesezen, also kann schon aber man entlistet die jawohl
Ein solcher Zufall ohne Datenspeicherung, bei dem jede ID unterschiedlich ist, ist unmöglich.* Eine Restwahrscheinlichkeit bleibt immer vorhanden. Also gilt es meiner Meinung nach entweder: a) die Wahrscheinlichkeit so niedrig wie möglich zu halten, oder b) einen pseudozufälligen Algorithmus zu entwickeln, der halt einfach eine gewisse Gesetzmässigkeit befolgt, die aber kaum auffällt, bzw. schwer zu beobachten ist. Sprich, dass mit jeder Charakterkreation theoretisch die Zahl errechenbar ist.
Für a) könnte man sich folgendes überlegen:
Je mehr IDs gemacht werden, desto grösser wird die Wahrscheinlichkeit für eine Überschneidung. Es gibt 999'999 Möglichkeiten für die IDs ohne Berücksichtigung der 000'000. Das heisst, beim ersten Typen, der sich eine ID macht ist die Wahrscheinlichkeit für eine Überschneidung ja 0 / 999'999. Beim zweiten dann 1 / 999'999. Somit ist die Wahrscheinlichkeit bei einem Optimalen Algorithmus für eine Überschneidung (x - 1) / 999'999 wobei x die Anzahl an Charakteren darstellt. Das heisst folglich: Je mehr Leute joinen, desto höher die Wahrscheinlichkeit einer Überschneidung. Ausserdem ist diese Wahrscheinlichkeit da oben nicht so klein. Ergo: Ansatz a) scheint der Falsche Ansatz zu sein. Meiner Meinung nach sind demnach alle Ansätze mit Wahrscheinlichkeit nicht wirklich sinnvoll.
Somit bleibt Option b) die einzige, die wirklich praktikabel ist und eine Wahrscheinlichkeit einer Überschneidung gleich 0 setzt. D.h. die Aufgabe kann man wie folgt umschreiben:
Schreibt einen Algorithmus, welcher bei einem zufälligen Punkt startet, und von da an gewisse Operationen durchführt, die gewährleisten, dass
a) es schwierig ist, den Algorithmus rauszufinden
b) einen genügend grossen Abstand zwischen den IDs ermöglicht, aber gleichzeitig sich nicht allzu schnell wiederholt (Wiederholung ist zwangsläufig da)
c) keine Zahl zwei Mal errechnet
d) die Zahl 999'999 nicht überschritten wird.
Die erste Art eines solchen Algorithmus' ist es natürlich immer +1 zu rechnen. Aber es gibt auch andere Wege. Beispielsweise mit +3: Jeder Char bekommt eine Zahl die der vom vorherigen Char entspricht +3. Wenn die Zahl dann 999'999 überschreitet, sprich 1'000'002 ist, rechnet man immer Modulo 1'000'000 Mit diesem Algorithmus wäre bspw. schon die Einzigartigkeit gewährleistet. Es gibt viel mehr Möglichkeiten, daher kann man da sehr kreativ werden.
Das scheint mir jetzt eher eine mathematische Knobelei als eine wirklich programmiertechnische. Ich werde wahrscheinlich noch über einen möglichen Algorithmus nachdenken, aber ich wollt das alles mal so geschrieben haben, damit sich die Leute den Zufall aus dem Kopf schlagen können (ausser beim Einstiegspunkt).
LG ~Oly
P.S:
*Warum so ein Zufall unmöglich ist:
Stellen wir uns das Problem doch ganz einfach bei einstelligen Zahlen vor: Da haben wir die Ziffern 0 bis 9. Nun lassen wir zufällig 9 Ziffern rausnehmen. Eine bleibt. Sagen wir mal die 2. Nun muss es möglich sein, die Zahl 2 mit jeder der von 0 bis 9 zufällig generierten Ziffern zu errechnen ohne der Kenntnis aller anderen vorherigen Ergebnisse. Auch könnte rein mathematisch das Endergebnis alle Zahlen sein, da wir keine Zahl zwischen 0 und 9 ausschliessen können, bzw. keine Information haben über die vorherigen Zahlen. Somit ist ein solcher Algorithmus gar nicht erst möglich.
Dieser Beweis ist mir eingefallen, als ich mit Elias geredet habe. Ich hab ihm die Aufgabenstellung erklärt, halt nur mit einer Ziffer. Aber danach ist es mir eingefallen. Danke für die "Inspiration" Elias (4) xD
Es ist nicht unmöglich, man bräuchte lediglich eine praktikable Funktion.
Da existiert für jeden X Wert nur ein Y-Wert, somit existieren keine Überschneidungen.
Ich dachte erst daran, man könne die Sinusfunktion verwenden ( f(x)=sin(x) ) und die erste Zahl in der ID entspräche immer den X-Wert (X=CID), wobei man dort auf das Problem stößt, dass die Sinusfunktion nur einen Wertebereich von -1 bis 1 besitzt.
Man braucht also nur eine Funktion, die nur eine geringe Steigung besitzt und die 6-Stellige ID müsste sinnvoll in x-Werten und y-Werten (Nachkommastallen?) aufgeteilt werden. Hatte leider nur noch keine Zeit diese Funktion sinngemäß zu bilden.
Es ist nicht unmöglich, man bräuchte lediglich eine praktikable Funktion.
Da existiert für jeden X Wert nur ein Y-Wert, somit existieren keine Überschneidungen.
Ich dachte erst daran, man könne die Sinusfunktion verwenden ( f(x)=sin(x) ) und die erste Zahl in der ID entspräche immer den X-Wert (X=CID), wobei man dort auf das Problem stößt, dass die Sinusfunktion nur einen Wertebereich von -1 bis 1 besitzt.
Man braucht also nur eine Funktion, die nur eine geringe Steigung besitzt und die 6-Stellige ID müsste sinnvoll in x-Werten und y-Werten (Nachkommastallen?) aufgeteilt werden. Hatte leider nur noch keine Zeit diese Funktion sinngemäß zu bilden.
Klar. Auch beim Sinus ist ein solches Konzept des Zufalls an Wahrscheinlichkeit gebunden. Das Problem ist ja nicht, dass die Funktion nur einen möglichen Y-Wert pro X-Wert hat (sonst wäre es btw. keine Funktion), sondern dass der X-Wert nicht jedes Mal ein zufällig anderer sein kann ohne dass Daten vorheriger X-Werte bestehen. D.h. es besteht bei jeder Neubildung ohne Datenbank die Möglichkeit des gleichen Y-Wertes.
Ausserdem ist gerade beim Sinus eine Einschränkung des Wertebereiches notwendig von -π bis π bzw. -90 bis 90. Die Funktion ist aber ansonsten bis 1'000'000 erweiterbar. Die Funktion wäre dann einfach
f(x) = (maxnum / 2) * (sin(x) + 1)
wobei gilt: -π/2 < x < π/2
maxnum wäre dann wie hoch man gehen will (bspw. 1'000'000)
Aber mit dem Sinus generell eine Funktion herzuleiten ist eig. ne ziemlich gute Idee.
Ich dachte erst daran, man könne die Sinusfunktion verwenden ( f(x)=sin(x) ) und die erste Zahl in der ID entspräche immer den X-Wert (X=CID), wobei man dort auf das Problem stößt, dass die Sinusfunktion nur einen Wertebereich von -1 bis 1 besitzt.
Ausserdem ist gerade beim Sinus eine Einschränkung des Wertebereiches notwendig von -π bis π bzw. -180 bis 180. Die Funktion ist aber ansonsten bis 1'000'000 erweiterbar. Die Funktion wäre dann einfach
f(x) = (maxnum / 2) * (sin(x) + 1)
wobei gilt: -π < x < π
maxnum wäre dann wie hoch man gehen will (bspw. 1'000'000)