Programm crasht bei vielen Berechnungen ohne exception

[PierreDole]

Moin,
ich möchte das beste Verhältnis zwischen einem Multiplikator und zwei Konstanten berechnen. Das passiert in drei for-Schleifen, die zusammen 64.000.000 Mal durchlaufen sollen, wenn ich mich nicht verrechnet habe. Das Programm crasht jedoch schon sehr schnell (Bruchteil einer Sekunde) ohne exception. Bei mehreren Versuchen kam der Counter auf 2000 bis 9000.

Das Einzige, was in der Console steht, ist: Process finished with exit code -1073740940 (0xC0000374). Danach googlen brachte nichts.

Das Ganze passiert in python 3.9. Als UI verwende ich pyqt5.

Woran könnte es liegen?

Code: Alles auswählen

    def start(self) -> None:
        thread = Thread(target=self.calculate2)
        thread.start()

    def calculate2(self) -> None:
        counter: int = 0
        
        # result values
        rw1: float = 1000
        rw2: float = 1000
        rw3: float = 1000
        rw4: float = 1000
        rMulti: float = 0
        rConst1: int = 0
        rConst2: int = 0

        for i, v in enumerate(np.arange(0, 10, 0.1)):
            for const1 in range(800):
                for const2 in range(800):
                    multi = round(v, 1)
                    ms1 = 1.1 * multi
                    ms2 = 2.1 * multi
                    ms3 = 3.1 * multi
                    ms4 = 4.1 * multi

                    w1 = 1259 + const1 - (const2 * (1 - pow(2, (ms1 * -1))))
                    w2 = 1259 + const1 - (const2 * (1 - pow(2, (ms2 * -1))))
                    w3 = 1259 + const1 - (const2 * (1 - pow(2, (ms3 * -1))))
                    w4 = 1259 + const1 - (const2 * (1 - pow(2, (ms4 * -1))))

                    wSum = (abs(w1 - self.default1) +
                            abs(w2 - self.default2) +
                            abs(w3 - self.default3) +
                            abs(w4 - self.default4))

                    rwSum = (abs(rw1 - self.default1) +
                             abs(rw2 - self.default2) +
                             abs(rw3 - self.default3) +
                             abs(rw4 - self.default4))

                    if wSum < rwSum:
                        rw1 = w1
                        rw2 = w2
                        rw3 = w3
                        rw4 = w4
                        rMulti = multi
                        rConst1 = const1
                        rConst2 = const2

                    counter += 1
                    self.lbl_progress.setText(str(counter))

        self.lbl_progress.setText("multi: " + str(round(rMulti, 1)) + "\n"
                                  "const1: " + str(rConst1) + "\n"
                                  "const2: " + str(rConst2) + "\n"
                                  "1.1: " + str(round(rw1)) + " / " + str(self.default1) + "\n"
                                  "2.1: " + str(round(rw2)) + " / " + str(self.default2) + "\n"
                                  "3.1: " + str(round(rw3)) + " / " + str(self.default3) + "\n"
                                  "4.1: " + str(round(rw4)) + " / " + str(self.default4))

[PierreDole]

Ich hab's raus.
Sieht so aus, als würde Pyqt5 es nicht mögen, wenn man zu schnell den Text eines Labels ändert.

Habe den Output begrenzt:

Code: Alles auswählen

                    if counter % 1000 == 0:
                        self.lbl_progress.setText(str(counter))

Jetzt zählt der Counter in 1000er Schritten hoch.

[pillmuncher]

Nein. Dein Problem besteht darin, dass du nicht aus einem anderen Thread heraus an der GUI herumfummeln darfst. GUIs mögen das überhaupt nicht gerne. Statt dessen solltest du Signals, Slots, oder eine Queue benutzen, um dem GUI-Thread mitzuteilen, wenn neue Daten vorliegen.

[PierreDole]

Danke, gut zu wissen.
Das war auch etwas quick and dirty geschrieben, nur um einmal die gewünschten Werte herauszufinden. Dafür hätte ich mich nicht in Signale usw. eingelesen. Letztendlich hat es geklappt. Das Ganze dauerte 5 1/2 Minuten und ich bin vom Ergebnis begeistert. Es ist nahezu perfekt. Hätte es so nicht erwartet.

[imonbln]

Generell zu dein Programm, du machst viele unnötige Berechnungen. Wenn es so viele hat, wie du wirkt das sich ungünstig auf die Performance aus. Überlege die welche Terme in welcher Forschleife berechnet werden können und berechne die Terme so bald sie bekannt sind.

Außerdem wenn du Variablen 1-4 als Suffix anhängst, dann ist das ein eindeutiges Zeichen, das es keine Variablen sind, sondern ein Array.
Generell tust du den nächsten auch einen großen gefallen, wenn du sprechende Variablen verwendest. Eine Variable, die nur aus einem Buchstaben besteht, ist meistens nicht hilfreich für das Verständnis. Die Variablen der Forschleife const zu nennen ist fast schon kriminell, denn die sind ja gerade nicht konstant.

rwSum kannst du einmal vor den Forschleifen berechnen und wenn die If Abfrage wahr ist mit rwSum mit wSum überschreiben. Der Factor 1259 + const1 kann in der 2 Forschleife berechnet werden und dann als Hilfsvariable gespeichert werden. Die Variablen msX brauchst du nicht, da kannst du gleich "1 - pow(2, (msX * -1)))" brechenen. Die Variable i wird niegends verwendet.

[PierreDole]

Generell zu dein Programm, du machst viele unnötige Berechnungen. Wenn es so viele hat, wie du wirkt das sich ungünstig auf die Performance aus. Überlege die welche Terme in welcher Forschleife berechnet werden können und berechne die Terme so bald sie bekannt sind.

Außerdem wenn du Variablen 1-4 als Suffix anhängst, dann ist das ein eindeutiges Zeichen, das es keine Variablen sind, sondern ein Array.
Generell tust du den nächsten auch einen großen gefallen, wenn du sprechende Variablen verwendest. Eine Variable, die nur aus einem Buchstaben besteht, ist meistens nicht hilfreich für das Verständnis. Die Variablen der Forschleife const zu nennen ist fast schon kriminell, denn die sind ja gerade nicht konstant.

rwSum kannst du einmal vor den Forschleifen berechnen und wenn die If Abfrage wahr ist mit rwSum mit wSum überschreiben. Der Factor 1259 + const1 kann in der 2 Forschleife berechnet werden und dann als Hilfsvariable gespeichert werden. Die Variablen msX brauchst du nicht, da kannst du gleich "1 - pow(2, (msX * -1)))" brechenen. Die Variable i wird niegends verwendet.

Ich muss zugeben, ich habe selten so viel Nonsens gelesen. Lese dir bitte nochmal durch, was ich oben geschrieben habe, falls du es überhaupt einmal getan hast.
Auch mit 35 Jahren Programmiererfahrung in anderen Sprachen habe ich immer noch das Recht gewisse Dinge "quick and dirty" zu gestalten. Vor allem, wenn ich erstmal nur sehen will, ob eine Idee überhaupt funktioniert und erst recht, wenn das Programm, wenn es einmal getan hat, was es soll, nie wieder benutzt wird.
Nein, wenn ich an Variablennamen 1 bis 4 anhänge, dann muss das kein Array sein. Was für komische Regeln denkst du dir da aus? Ich kann da einfach nur den Kopf schütteln.
Ja, const1 und const2 sind hier Variablen, aber, und jetzt pass gut auf, was ich dir sage: Es geht darum zwei Konstanten zu finden.

[noisefloor]

Hallo,

du kannst für dich selber den Code schreiben, wie du willst, keine Frage. Nur: was du in deinem stillen Kämmerlein machst und was du öffentlich (wie hier im Forum) zeigst, ist halt zweierlei. Dein Code entspricht halt an einigen Stellen nicht den Coding Konventionen (Stichwort: PEP8) und der gängigen "best pratice" für Python. Dabei spielt es auch so gar keine Rolle, ob du 35 Jahre oder 35 Tage programmierst.

Du hast nach Hilfe gefragt, du hast Hilfe bekommen, recht umfassend. Wenn's dir das nicht passt - ignorier' es einfach oder frag' in Zukunft nicht mehr hier nach. Aber versuchen , Hilfswillige rund zu machen, weil sie dir Tipps zum Code geben, die dir nicht passen, ist halt kein brauchbares Sozialverhalten, weder im realen Leben noch im virtuellen Leben im Forum.

Gruß, noisefloor

[PierreDole]

Hallo,

du kannst für dich selber den Code schreiben, wie du willst, keine Frage. Nur: was du in deinem stillen Kämmerlein machst und was du öffentlich (wie hier im Forum) zeigst, ist halt zweierlei. Dein Code entspricht halt an einigen Stellen nicht den Coding Konventionen (Stichwort: PEP8) und der gängigen "best pratice" für Python. Dabei spielt es auch so gar keine Rolle, ob du 35 Jahre oder 35 Tage programmierst.

Du hast nach Hilfe gefragt, du hast Hilfe bekommen, recht umfassend. Wenn's dir das nicht passt - ignorier' es einfach oder frag' in Zukunft nicht mehr hier nach. Aber versuchen , Hilfswillige rund zu machen, weil sie dir Tipps zum Code geben, die dir nicht passen, ist halt kein brauchbares Sozialverhalten, weder im realen Leben noch im virtuellen Leben im Forum.

Gruß, noisefloor

Für den Teil, der mir geholfen hat, habe ich mich auch bedankt. Aber was imonbln hier von sich gegeben hat, war für mich nicht ernst zu nehmen. Es zeigte mir nur, daß er meine Posts nicht durchgelesen hat und somit kein Interesse hatte darauf einzugehen. Und ich bin einer mit sehr viel Humor. Jemanden "rund zu machen" war nicht meine Absicht.

[Sirius3]

Was man in Code nicht haben möchte, ist, stumpf etwas zu kopieren und leicht anzupassen, und da zählt eindeutig das Kopieren von Zeilen und das anpassen einer Zahl dazu.
Warum man das nicht machen möchte, ist leicht verständlich: es führt zu mehr Code den man verstehen muß und die Praxis zeigt, dass man beim Anpassen häufig Fehler macht.
Das ist also keine ausgedachte Regel, sondern die Regel, die sich intelligente und vernünftige Leute aus ihrer Erfahrung abgeleitet haben, und die viele andere Programmierer selbst als sinnvoll erachten.

Da Du eh schon numpy einsetzt, wäre es logisch, dafür numpy-Arrays einzusetzen.

Code: Alles auswählen

    def calculate2(self):
        factors = np.array([1.1, 2.1, 3.1, 4.1])
        defaults = np.array([
            self.default1,
            self.default2,
            self.default3,
            self.default4,
        ])
        min_sum = float('inf')
        best_w = None
        best_multi = None
        best_const1 = best_const2 = None

        for multi in np.arange(0, 10, 0.1):
            for const1 in range(800):
                for const2 in range(800):
                    w = 1259 + const1 - const2 * (1 - 2**(-factors * multi))
                    w_sum = abs(w - defaults).sum()
                    if w_sum < min_sum:
                        min_sum = w_sum
                        best_multi = multi
                        best_w = w
                        best_const1 = const1
                        best_const2 = const2

        text = [
            f"multi: {best_multi:.1f}"
            f"const1: {const1}"
            f"const2: {const2}"
        ] + [
            f"{f:.0f}: {w:.0f} / {d}"
            for f, w, d in zip(factors, best_w, defaults)
        ]
        self.lbl_progress.setText("\n".join(text))

[PierreDole]

Was man in Code nicht haben möchte, ist, stumpf etwas zu kopieren und leicht anzupassen, und da zählt eindeutig das Kopieren von Zeilen und das anpassen einer Zahl dazu.
Warum man das nicht machen möchte, ist leicht verständlich: es führt zu mehr Code den man verstehen muß und die Praxis zeigt, dass man beim Anpassen häufig Fehler macht.
Das ist also keine ausgedachte Regel, sondern die Regel, die sich intelligente und vernünftige Leute aus ihrer Erfahrung abgeleitet haben, und die viele andere Programmierer selbst als sinnvoll erachten.

Da Du eh schon numpy einsetzt, wäre es logisch, dafür numpy-Arrays einzusetzen.

Code: Alles auswählen

    def calculate2(self):
        factors = np.array([1.1, 2.1, 3.1, 4.1])
        defaults = np.array([
            self.default1,
            self.default2,
            self.default3,
            self.default4,
        ])
        min_sum = float('inf')
        best_w = None
        best_multi = None
        best_const1 = best_const2 = None

        for multi in np.arange(0, 10, 0.1):
            for const1 in range(800):
                for const2 in range(800):
                    w = 1259 + const1 - const2 * (1 - 2**(-factors * multi))
                    w_sum = abs(w - defaults).sum()
                    if w_sum < min_sum:
                        min_sum = w_sum
                        best_multi = multi
                        best_w = w
                        best_const1 = const1
                        best_const2 = const2

        text = [
            f"multi: {best_multi:.1f}"
            f"const1: {const1}"
            f"const2: {const2}"
        ] + [
            f"{f:.0f}: {w:.0f} / {d}"
            for f, w, d in zip(factors, best_w, defaults)
        ]
        self.lbl_progress.setText("\n".join(text))

Ich will dem gar nicht widersprechen, daß es in Python anders gemacht wird oder gemacht werden kann. Das war aber auch nicht mein Anspruch.
Das Projekt, für das ich den Multiplikator und die beiden Konstanten brauche, schreibe ich in AngelScript. Von da habe ich es auch rauskopiert und etwas angepasst. Dort habe ich die Formal nur eimal. In Python habe ich sie vervielfältigt, damit ich sehe, ob das Ergebnis auch mit anderen Parametern richtig ist. Daran hat es auch in AS gelegen. mit 1.1 gekam ich einrichtiges Ergebnis. Mit anderen Zahlen nicht.
Die Konstanten und den Multiplikator habe ich in AS versucht per Hand anzupassen, merkte aber schnell, das wird ewig dauern. Ich brauchte also schnell eine GUI mit drei Slidern, die Sprache dafür war egal. Aber auch mit den Slidern kam ich nicht auf die gewünschten Werte. Dann stelle sich die Frage, wie lange würde es überhaupt dauern, von der Laufzeit her, wenn ich die Werte von 0 bis X hochzähle und alle Kombinationen ausprobiere. Minuten, Stunden? Wird es überhaupt mit der Formel möglich sein die gewünschten Werte zu bekommen oder liegt es doch an Mathematik. Um mir nur Fragen zu beantworten, schreibe ich jetzt nicht etwas großartig hübsch und lese mich auch nicht in Bibliotheken ein, um zu erfahren, was sie nicht alles können und ob ich mit ihnen den Code nicht besser gestalten könnte. In AS hingegen, ist das alles schön nach Konvention geschrieben, so wie es sein soll.

[DeaD_EyE]

Nein, wenn ich an Variablennamen 1 bis 4 anhänge, dann muss das kein Array sein. Was für komische Regeln denkst du dir da aus? Ich kann da einfach nur den Kopf schütteln.

Deswegen z.B.: https://de.wikipedia.org/wiki/Advanced_ ... Extensions