bestimmte Wörter generieren?

2 Antworten

Dafür musst du halt die Basics können. Folgendes brauchst du:

  • String.fromCharCode()
  • <dein String>.charCodeAt()
  • for-Schleifen (in diesem Fall sogar zwei, eine innerhalb der anderen)
  • Value eines Inputs in JavaScript auslesen
  • Per JavaScript Text in HTML einfügen
  • async, await, Promise und setTimeout, um eine bestimmte Zeit nach jedem Buchstaben zu warten

Hab das ganze mal programmiert, aber versuch es am besten selbst: https://jsfiddle.net/bxap5ck0/

Woher ich das weiß:Hobby – Programmieren ist mein Hobby & Beruf

Ricardo286 
Beitragsersteller
 06.04.2022, 12:21

danke sehr, sie sind mir eine große Hilfe :)

1

Du schreibst dir eine Schleife, die endlich oft folgendes tut:

Einen zufälligen Buchstaben generieren (Math.random in einen passenden Range mappen) und diesen ausgibt.

Diesen Buchstaben dann anzeigt und etwas wartet.

Wenn die Schleife durchgelaufen ist, dann zeigst du den Buchstaben an, den du anzeigen möchtest.


MrAmazing2  30.03.2022, 14:21

Oder 'ne while-Schleife bis der richtige Buchstabe durch zufall angezeigt wird

0
Destranix  30.03.2022, 14:22
@MrAmazing2

Dann läuft das Programm womöglich ewig, das wäre denke ich nicht gewünscht.

0
MrAmazing2  30.03.2022, 14:27
@Destranix

Bei einer Chance von 1/29 läuft das definitiv nicht lange, das ist noch völlig im Rahmen. Aber stimmt, hundert Versuche kann das schonmal brauchen pro Buchstabe..

1
MrAmazing2  30.03.2022, 15:09
@Destranix

In der Theorie, klar, aber das ist beim Programmieren so ziemlich egal.

Das ist wie wenn man keine UUIDs benutzen will weil "in der Theorie könnte es Duplikate geben"

0
Destranix  30.03.2022, 15:13
@MrAmazing2

Das sollte beim Programmieren nicht egal sein. Das kann man an einzelnen, wenigen Punkten einsetzen, beispielsweise wenn man unbedingt höhere Performance braucht und das dadurch bewirken kann (e.g. beim finden von Primzahlen), aber ansonsten sorgt das nur für Unsicherheitsfaktoren und schlechtem Code.

Das ist wie wenn man keine UUIDs benutzen will weil "in der Theorie könnte es Duplikate geben"

Korrekt. Deshalb würde ich unregistrierte UUIDs auch nur vorsichtig verwenden und, wenn ich es nicht vergesse, einen Mechanismus einbauen, der abfängt, wenn diese bereits vergeben wurde.
Wenn man nur sehr wenige UUIDs braucht, kann man vielleicht darauf verzichten, aber sonst würde ich das eher nicht tun.

0
MrAmazing2  30.03.2022, 15:18
@Destranix
Deshalb würde ich unregistrierte UUIDs auch nur vorsichtig verwenden und, wenn ich es nicht vergesse, einen Mechanismus einbauen, der abfängt, wenn diese bereits vergeben wurde.

Auf Stackoverflow würden sie dich für diese Aussage zu tode disliken xD

https://stackoverflow.com/a/53471187/10686377

0
Destranix  30.03.2022, 15:20
@MrAmazing2

Sollen sie doch! Ich habe ja bereits erwähnt, dass es Ausnahmen gibt, aber Good Practice wäre es definitiv, wenn möglich auch unwahrscheinliche Fälle abzufangen.

0
MrAmazing2  30.03.2022, 15:45
@Destranix

Also im Fall des Fragestellers gebe ich dir recht, denn da wären selbst 100 oder 1000 Versuche schon zu viel, da nach jedem Versuch eine Zeit gewartet werden soll.

Aber bei UUIDs fällt das für mich unter "premature optimization is the root of all evil".

Und auch generell ist nichts falsch daran, so lange etwas zufällig zu wählen, bis man das richtige erwischt.

Zum Beispiel bei Snake um ein freies Feld für den Apfel zu finden. Einfach solange ein zufälliges Feld wählen, bis man ein leeres hat. Klar, eine Liste aller leeren Felder zu erstellen und davon eins auszuwählen wäre besser, aber muss nicht, ist unnötiger Aufwand. Dafür lernt man im Studium Statistik. Gegenwahrscheinlichkeit ^ Versuche. Sagen wir man hat 400 Felder und nurnoch eins davon ist leer, dann gilt: log mit basis 399/400 von 0,001 = 2759. Heißt selbst im 0,1% Worst-Case braucht der Algorithmus nur 2759 Durchläufe, um dieses Feld zu finden. Das hat der Computer in ein paar Nanosekunden. Beim 0,01%-Worste-Case, also 1 von 10000 Fällen, auch nur 3679 Durchläufe. Das ist nix. Und so gehts immer weiter. Die Anzahl an nötigen Versuchen steigt nicht groß.
Hier, das habe ich letztens gesehen, sehr interessant, da geht's um Performance und Premature Optimization: https://www.youtube.com/watch?v=o4-zpAI7qBc
Man kann ruhig den scheinbar schlechteren aber deutlich kürzeren Lösungs-Ansatz wählen, wenn der Computer dafür nur ein paar Tausend Durchläufe mehr braucht.

Aber ich muss gestehen, ich neige auch selbst oft zu premature optimization. Manchmal hat man halt nicht gleich im Kopf, wie schwer oder wie vernachlässigbar sich etwas auf die Performance auswirken würde.

1
Destranix  30.03.2022, 16:05
@MrAmazing2
Aber bei UUIDs fällt das für mich unter "premature optimization is the root of all evil".

Nicht unbedingt.

Ich meine, wenn es wirklich nur soetwas ist wie:

while(alreadyExists(uuid){
    uuid = generateNewUUID();
}

Dann ist das ein bisschen Code, der nicht schadet, nicht kompliziert zu warten ist, aber einen möglicherweise, wenn auch unwahrscheinlich, auftretendem Fehler vorbeugt.

Wenn das jetzt an einer Stelle im Code getan wird, die zeitkritisch ist, würde ichd as auch nicht machen oder wenn ich nicht prüfen könnte, ob es die UUID schon gibt oder wenn ich die sowieso nur selten generiere oder ...
Aber wenn ich kann, warum sollte ich nicht?

Einfach solange ein zufälliges Feld wählen, bis man ein leeres hat.

Und wenn es blöd läuft ist das Feld voller Äpfel und plötzlich tauchen keine neuen Äpfel mehr auf, da es kaum freie Felder gibt und andauernd volle gewählt werden.

Okay, wenn es eine Obergrenze für Äpfel gibt ist das vielleicht nicht problematisch, aber wenn man soetwas tut, dann muss man das auf jeden Fall bewusst entscheiden und gut überdenken, sonst entstehen leicht Fehler, die man womöglich nur schwer findet.
Zudem sollte man einen passenden Kommentar dazuschreiben.

Mal ganz davon abgesehen: Oftmals kommt man um so Dinge auch garnicht drumherum, da sie von Bibliotheken oder betriebssystem genutzt werden (und sogar auf physikalischer Ebene ist der Computer voll von Dingen, die zwar mit hoher Wahrscheinlichkeit, aber eben nicht mit absolut hundertprozentiger funktionieren). Beispielsweise wenn es um Synchronisation geht (z.B. Compare-And-Swap Zeugs. Habe leider vergessen, wie das hies, was ich meinte, aber findet man ja an etlichen Stellen soetwas.) oder der Arbeitsspeicher, der sogar in realistischen Szenarien zufällige Bitfehler aufweist.

Manchmal hat man halt nicht gleich im Kopf, wie schwer oder wie vernachlässigbar sich etwas auf die Performance auswirken würde.

Zumal man sich darum auch später kümmern könnte, wenn die Performance nicht ausreicht. Von ordentlichem Code zu unordentlichem geht es zumeist leichter.

1
Ricardo286 
Beitragsersteller
 06.04.2022, 12:21
@Destranix

Vielen Dank für eure ausführlichen antworten :p

1