Automatische Einrücküberarbeitung

[STARGÅTE]

zu den Fragen :

Wurde alle richtig beantwortet, random(10) war einfach nur dafür, das er nicht mit jedem durchlauf aktuallisiert.

WindowEvent brauche ich (bei 3.3) damit das SetGadget() umgesetzt wird, sonst habe ich ein leeres Fenster wo nix passiert.

Loc = Int(Loc()/Lof()*290)
funzt problemlos, und ich denke das liegt auch am INT, denn ich hatte schon mal probs damit wenn ich INT weglasse, das dann als ergebnis immer 0 kam.

Bei dir würde ja "theoretisch" auch ein Prob kommen :
290*Loc(1)/Lof(1), denn wenn Loc() doch mal "sehr groß" wird, wäre 290*Loc auch außerhalb von INT und es kommt zu falschen werten.

[Kaeru Gaman]

der gag ist, dass die umgekehrte reihenfolge dafür sorgt, dass selbst als integer feine werte rauskommen.

gesetzt den fall, Loc ist 32000 und Lof ist 42000.

als int ist 32000/42000 = 0, mal 290 ist immer noch null.

290*32000 ist aber 9'280'000, wenn ich das durch 42000 teile, kommt auch als integer 220 raus.

> 290*Loc(1)/Lof(1), denn wenn Loc() doch mal "sehr groß" wird, wäre 290*Loc auch außerhalb von INT und es kommt zu falschen werten.

genau.
dort bekomme ich das problem, dass ich die obergrenze eines Long nicht überschreiten darf,
sonst kommt es durch den overflow zu falschen ergebnissen.

merke:
die reihenfolge der werte innerhalb einer rechnung kann bei der programmierung von immenser bedeutung sein,
auch wenn die formel mathematisch identisch ist.

[michel51]

290*32000 ist aber 9'280'000, wenn ich das durch 42000 teile, kommt auch als integer 220 raus.

> 290*Loc(1)/Lof(1), denn wenn Loc() doch mal "sehr groß" wird, wäre 290*Loc auch außerhalb von INT und es kommt zu falschen werten.

genau.
dort bekomme ich das problem, dass ich die obergrenze eines Long nicht überschreiten darf,
sonst kommt es durch den overflow zu falschen ergebnissen.

merke:
die reihenfolge der werte innerhalb einer rechnung kann bei der programmierung von immenser bedeutung sein,
auch wenn die formel mathematisch identisch ist.

Ich stimme zu, den Überlauf zu vermeiden bei großen Dateien sollte ein Ziel sein.
Das Beispiel oben mal anders herum aufgezogen:
Lof() ist in jedem Fall immer größer als Loc().
Daher ist Lof()/Loc() immer > 0, ausser Loc() ist Null!
Also rechnen wir doch mit dem Kehrwert:

Loc = Int(290/(Lof()/Loc())

Mit dieser Rechnung dürfte es keinen Überlauf geben, da erst die Division Lof()/Loc() ausgeführt wird, und das Ergebnis kann maximan Lof() sein.
Das muss dann aber eine "Sehr sehr sehr" große Datei sein.
Ich hoffe, ich habe mich jetzt nicht vertan, aber mein Taschenrechner lügt nur, wenn ich mich vertippe

[Kaeru Gaman]

> Daher ist Lof()/Loc() immer > 0, ausser Loc() ist Null!

ich habe den eindruck, du hast den kern doch nicht verstanden.
einen überlauf zu vermeiden war der zweite punkt den ich erwähnt habe.

probier diesen code mal aus:

Code: Alles auswählen

Loc = 31456
Lof = 56392

Balken = 290/(Lof/Loc)

Debug Balken

falls du dich über das ergebnis wunderst, les mein vorletztes posting noch mal.

[al90]

Aaahh.., gerade fällt mir ein, das direkte Starten einer .pb Datei (Doppelklick) mit gleichzeitigem Öffnen von Purebasic funktioniert auf (meinem) Mac nicht. Weiss aber noch nicht warum.

Kennst du eine Methode, wie man den geänderten Code (also "Filename.pb.pb") in den Editor laden kann zum anzeigen?

Probiere es mal so:

Code: Alles auswählen

Source$="C:\MySource.pb"

RunProgram(#PB_Compiler_Home+"PureBasic.exe",Source$,#PB_Compiler_Home,#PB_Program_Wait)

[michel51]

Code: Alles auswählen

Source$="C:\MySource.pb"

RunProgram(#PB_Compiler_Home+"PureBasic.exe",Source$,#PB_Compiler_Home,#PB_Program_Wait)

Funktioniert leider auch nicht. Hier mein Versuch:

Code: Alles auswählen

RunProgram(#PB_Compiler_Home+"PureBasic.app","FileName.s+".pb", #PB_Compiler_Home, #PB_Program_Wait)

Ich weiss nicht, ob das so richtig ist. Vielleicht kann ja mal ein Mac-Spezialist hier aushelfen
Auf jeden Fall bekomme ich die Datei "FileName.s+".pb" (noch immer) nicht automatisch in den Editor.

[Kiffi]

Hier mein Versuch:

Code: Alles auswählen

RunProgram(#PB_Compiler_Home+"PureBasic.app","FileName.s+".pb", #PB_Compiler_Home, #PB_Program_Wait)

ich kenne mich mit dem Mac nicht aus, aber ich denke, dass der Compiler
auch dort meckern wird, wenn man die Anführungsstriche falsch setzt.

Zusätzlich: Hast Du Dir FileName.s schon mal testweise ausgeben lassen?

Code: Alles auswählen

Debug FileName.s

Stimmt der Pfad?

Grüße ... Kiffi

[michel51]

probier diesen code mal aus:

Code: Alles auswählen

Loc = 31456
Lof = 56392

Balken = 290/(Lof/Loc)

Debug Balken

Balken = 290

OK, "/" ist eine Integerdivision, daher ist der Prozessbalken schnell voll als die Abarbeitung erledigt ist.

Durch das Umstellen von "290" nach vorne wird hier
290*Loc()/Lof()
verhindert, dass die Integerdivision Null wird. Die Formel wird von links nach rechts abgearbeitet.
Soweit richtig?

Hab den Code schon umgestellt.

Gibt es vielleicht eine andere Methode, den Prozessbalken zu füllen?
Allerdings ist ein Parameter ungewiss, nämlich die Anzahl der Umläufe.
Hmm.., ich glaube, ich werde mich da im Moment nicht tiefer eindenken.
So wie es ist läuft der Code (bis auf das Öffnen der Datei) und macht, was er soll.

[michel51]

Hier mein Versuch:

Code: Alles auswählen

RunProgram(#PB_Compiler_Home+"PureBasic.app","FileName.s+".pb", #PB_Compiler_Home, #PB_Program_Wait)

ich kenne mich mit dem Mac nicht aus, aber ich denke, dass der Compiler
auch dort meckern wird, wenn man die Anführungsstriche falsch setzt.

Hast recht, das ist aber nur ein Kopierfehler. Im Code ist es richtig, ohne ' " ' vor FileName.

Zusätzlich: Hast Du Dir FileName.s schon mal testweise ausgeben lassen?

Code: Alles auswählen

Debug FileName.s

Stimmt der Pfad?

Ja, der Pfad stimmt.

/Edit/ Oder meinst du einen anderen Pfad? Filename als Datei ist mit kpl. Pfad angegeben. Oder soll das was anderes stehen.
Die Hilfe ist in der Hinsicht leider nicht sehr hilfreich.

[al90]

Funktioniert leider auch nicht.

Was genau passiert denn ? Startet die IDE denn überhaupt ?
Wenn ja, meckert sie etwas an (Datei nicht gefunden o.ä.) ?