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
Im Prinzip ja. Aber immer noch nicht mehr als O(n).
Es handelt sich nicht um ein Optimierungsproblem.
Die Suche nach einem Extremum ist immer ein Problem der Ordnung O(n), wobei n die Anzahl der Daten ist. Wie man das asymptotisch verschlimmern kann - ich habe keine Ahnung.
Der einfachste Algorithmus ist ArraySort(), der schnell genug eingebaut ist, aber für dieses Problem wahrscheinlich überflüssig ist.
Sie könnten sich etwas Rekursives einfallen lassen, das schneller wäre.
Wie lange dauert es, das Minimum zu finden und für wie viele Takte?
Ich habe die Statistiken in meinem ersten Beitrag genannt. Die Berechnung für 1.000.000 Takte steigt arithmetisch mit zunehmender Dauer. Für den Zeitraum 3 dauert die Berechnung also 0,54 Sekunden, für den Zeitraum 51 0,94 Sekunden und für den Zeitraum 99 1,59 Sekunden.
Dies ist schlimmer, weil die Schleife in der Schleife verwendet wird, was ein Fehler ist. Für die Periode 3 beträgt die Anzahl der Iterationen also 1 000 000 * (3-1/2) = 1 000 000, während sie für die Periode 99 1 000 000 * (99-1)/2 = 49 000 000 beträgt! Daher müssen wir den Algorithmus so umschreiben, dass die Anzahl der Iterationen nicht mit zunehmender Periode qualitativ ansteigt - dies ist ein reines Optimierungsproblem. Das ist es, was ich jetzt tue. Bislang habe ich dies geschrieben:
Um das Minimum zu finden, wird die entsprechende Funktion Down() in einem parallelen Thread gestartet. Wenn beide Funktionen beendet sind, werden ihre Ergebnisse in die allgemeine Liste geschrieben. Es geht ungefähr so.
Siehst du, du hast es falsch verstanden. Es ist nicht die Summe einer reichhaltigen Progression, C-4. Die Summe wächst quadratisch.
OCL ist unzweideutig.
Der einfachste Algorithmus ist ArraySort(), der schnell genug ist, etwa O(n * ln( n ) ), aber für dieses Problem wahrscheinlich überflüssig ist.
Gedacht. Jede Sortierung ist inhärent langsamer als das Durchlaufen des gesamten Arrays mittels for. Denn es gibt eine Iteration, während arraysort bestenfalls Werte in jedem Teilfenster n sortiert, was wiederum Dutzende von Aktionen bedeutet.
Nein, Sie sollten dennoch anstreben, dass die Gesamtzahl der Iterationen qualitativ mit der Anzahl der Balken übereinstimmt.
Siehst du, du hast es falsch verstanden. Es ist nicht die Summe einer reichhaltigen Progression, C-4. Die Summe wächst quadratisch.
OCL ist unzweideutig.
Die Bedingung für eine solche Extremsuche ist, gelinde gesagt, seltsam... Aber selbst dann ist es äußerst unvernünftig, eine Brute-Force-Suchmethode anzuwenden.
Ein klassischer ZigZag mit ExtDepth = n in einem Durchgang kommt einem sofort in den Sinn, wenn man eine leichte Anpassung an die aktuelle Bedingung vornimmt. OCL ist hier zu 100 % unnötig.
Die Bedingung für eine solche Extremsuche ist, gelinde gesagt, seltsam... Aber selbst dann ist es äußerst unvernünftig, eine Brute-Force-Suchmethode anzuwenden.
Der klassische ZigZag mit ExtDepth = n in einem Durchgang kommt einem sofort in den Sinn, mit einer leichten Anpassung an die aktuellen Bedingungen. OCL ist hier zu 100 % unnötig.
Und warum? O(n) wird immer noch da sein, egal wie man es betrachtet.
Wenn alles andere fehlschlägt, versuchen Sie es mit OCL. Es gibt keine anderen Möglichkeiten, ohne dll-artige Perversionen in 5.