Generische Klassenbibliothek - Bugs, Beschreibung, Fragen, Nutzungsmöglichkeiten und Vorschläge - Seite 9
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Ich sollte hinzufügen, dass ich in der Lösung zwei Funktionen und ein Array verwendet habe. Keine Zeiger oder Verbindungen.
Ihre Lösung ist nicht gut. Sie haben bereits ein Array von 100x100x255, d.h. 2.550.000 Zellen, die für 100 Wörter reserviert sind! Und wenn Sie 10 000 000 Wörter haben, haben Sie die Speichergrenze auf 32-Bit-Systemen erreicht. Und was ist, wenn es mehr als 100 Kollisionen gibt? Wie viele Wörter beginnen mit dem Buchstaben S, und wie viele beginnen mit dem Buchstaben P? - Offensichtlich mehr als 100, warum sollten wir sie also nicht speichern?
D.h. man muss für jede Aufgabe das richtige Gleichgewicht zwischen der Größe des Wörterbuchs (RAM) und der Rechenkomplexität der Hash-Funktion (CPU) finden.
Nachdem ich all dies geschrieben hatte, fiel mir ein, dass es keine praktische Aufgabe ist, Zecken so zu speichern, wie es in diesem Thread diskutiert wird. Sie werden nach Zeit sortiert und in einem einfachen Array gespeichert.
Das Gleiche gilt für History Orders/Deals. Und nach HistorySelect zu urteilen, werden sie nach Zeit in einem Array gespeichert. Und ich denke, es gibt (in der derzeitigen Implementierung) nichts, was die Suche nach Datensätzen nach Ticket oder ID ermöglichen würde.
Und das alles nur, weil es im Falle der genannten Geschichte nicht sinnvoll ist, so etwas zu machen. Für die Praxis reicht eine einfache Anordnung aus.
Bitte schreiben Sie kurz und bündig, ohne Spoiler in Form von Hüten und überflüssigen Einheiten.
Dies ist ein Beispiel für eine Ausbildung, also entschuldigen Sie, aber nein. Ich möchte jedoch darauf hinweisen, dass der Code in der Kampfversion auf diese Weise geschrieben wird: so knapp und effizient wie möglich (so wie Sie es mögen). In den Schulungsbeispielen ist der Code für jedermann geschrieben, er ist so einfach und klar wie möglich, so dass auch ein unbedarfter Benutzer ihn verstehen kann.
s.w. Caps, ok, ich räume es auf.Ich möchte jedoch darauf hinweisen, dass der Code in der Kampfversion auf diese Weise geschrieben wird: so knapp und effizient wie möglich (genau so, wie Sie es mögen).
In der Praxis wird der Kodex bei Projekten nach dem "Verhaltenskodex" geschrieben.
Und eine solche Variante, wie im Fall vonfxsaber, wird nicht verwendet:
Der Grund dafür ist banal: Es ist unmöglich, die Fehler zu beheben.
Ihre Lösung ist nicht gut. Sie haben bereits ein Array von 100x100x255, d.h. 2.550.000 Zellen, die für 100 Wörter reserviert sind! Und wenn Sie 10 000 000 Wörter haben, erreichen Sie auf 32-Bit-Systemen die Speichergrenze. Und was ist, wenn es mehr als 100 Kollisionen gibt? Wie viele Wörter beginnen mit dem Buchstaben S, und wie viele beginnen mit dem Buchstaben P? - Sicherlich mehr als 100, warum sollten wir sie also nicht aufbewahren?
Ich bin zurückgekehrt, um den vorgeschlagenen Code vonReTeg Konow Code zu studieren.
Tut mir leid, aber das ist völliger Blödsinn und völlige Unkenntnis der Hash-Thematik im Allgemeinen, von Hash-Tabellen ganz zu schweigen.
Warum diesen Sarg auf Rädern bauen, wenn man sich bei hubr zumindest mit dem Thema Hashes vertraut machen kann?
Ja, es ist keine triviale Aufgabe, eine eigene Hashtabelle vernünftig zu implementieren.
Aber in den vorgeschlagenen Kodizes geht es nicht einmal um das Verständnis.
Freunde. Wie ich sehe, ist es um den Thread still geworden.
Ich möchte die Diskussion nicht stören, deshalb ziehe ich mich freiwillig zurück.
In der Bibliothek gibt es vielleicht eine Menge interessanter Dinge.
Sie können gerne darüber diskutieren.
(Meine Lösung ist auf jeden Fall schlechter, weil sie 3,2 Mal langsamer ist).
Ihre Lösung ist nicht gut. Sie haben bereits ein Array von 100x100x255, d.h. 2.550.000 Zellen, die für 100 Wörter reserviert sind! Und wenn Sie 10 000 000 Wörter haben, erreichen Sie auf 32-Bit-Systemen die Speichergrenze. Und was ist, wenn es mehr als 100 Kollisionen gibt? Wie viele Wörter beginnen mit dem Buchstaben S, und wie viele beginnen mit dem Buchstaben P? - Offensichtlich mehr als 100, warum sollten wir sie also nicht speichern?
Die Größe des Arrays kann leicht an die Größe des Wörterbuchs angepasst werden.
Ich halte nichts von endlosen Varianten.
Ich habe den vonRetag Konow vorgeschlagenen Code nochmals studiert.
Tut mir leid, aber das ist völliger Blödsinn und ein totales Missverständnis des Themas Hashes im Allgemeinen, ganz zu schweigen von Hash-Tabellen.
Warum sollten Sie diesen Sarg auf Rädern bauen, wenn Sie sich bei hubr zumindest mit dem Thema Hashes vertraut machen könnten.
Ja, es ist keine triviale Aufgabe, eine eigene Hashtabelle vernünftig zu implementieren.
Bei den angebotenen Codes ist jedoch nicht einmal von einer Verständigung die Rede.
Ihre Lösung ist nicht gut. Sie haben bereits ein Array von 100x100x255, d.h. 2.550.000 Zellen, die für 100 Wörter reserviert sind! Und wenn Sie 10 000 000 Wörter haben, haben Sie die Speichergrenze auf 32-Bit-Systemen erreicht. Und was ist, wenn es mehr als 100 Kollisionen gibt? Wie viele Wörter beginnen mit dem Buchstaben S, und wie viele beginnen mit dem Buchstaben P? - Offensichtlich mehr als 100, warum sollten wir sie also nicht speichern?
In meiner Version ist es unwahrscheinlich, dass es mehr als 100 Kollisionen geben wird. Fallen dir mehr als 100 Wörter ein, die mit einem Buchstaben beginnen und dieselbe Anzahl von Buchstaben haben?
(außer bei den Varianten "Text 1", "Text 2", "Text 3", "Text 4", "Text 5"...)