Entwickler-Ecke
Delphi Language (Object-Pascal) / CLX - Invalid floating point operation (0/0)
DeadlyAppearance - Di 22.07.08 15:34
Titel: Invalid floating point operation (0/0)
Ich grüße euch.
Und zwar folgendes Problem.
Delphi-Quelltext
1:
2:
3:
4:
5:
| var
Eisen, Titan : Int64;
Verhaeltnis : Single;
Verhaeltnis := RoundTo(Eisen/Titan,2); |
Das ganze funktioniert so lange bis Titan 0 ist, dann rappelt es.
Gibt es eine andere Möglichkeit außer mit if(Titan>0) dies abzufangen?
Xentar - Di 22.07.08 15:36
Was ist an der If-Abfrage so schlimm?
DeadlyAppearance - Di 22.07.08 15:39
Weil ich ca. 6 mal solch eine Rechnung in einer Schleife habe.
Dachte einmal aus Performancegründen kann es nicht schlecht sein 6 ifs zu sparen und mich interessiert es einfach, ob es einen anderen Lösungsweg gibt.
arj - Di 22.07.08 15:43
Du kannst, da Du nicht auf die Exaktheit deiner Lösung
angewiesen bist (RoundTo), und die Annahme treffen kannst, dass Titan >= 0 ist,
folgendes machen:
Delphi-Quelltext
1:
| Verhaeltnis := RoundTo(Eisen/(Titan+0.00000001),2);] |
Allerdings wird wohl die Addition zweier Fließpunktzahlen die
If-Abfrage an Laufzeit übertreffen...
Hidden - Mi 23.07.08 11:59
Hi,
Wenn es dir darum geht, die if-Abfrage nicht sechs Mal zu tippen, warum packst du das ganze nciht in eine eigene Prozedur?
mfG,
F34r0fTh3D4rk - Mi 23.07.08 12:10
Es geht ihm scheinbar nur um Performance und ich denke, dass 6-ifs immer noch das Performanteste sind, oder man an einer anderen Stelle optimieren sollte.
mfg
Allesquarks - Mi 23.07.08 13:39
Wenn ich mich recht erinner konnte man die ZeroDevide Exception im Coprozessor maskieren => assembler. Aber ich frage mich, wieso ein Rechnung bei der ein ungültiges Ergebnis entsteht überhaupt bei dir auftaucht.
Hidden - Mi 23.07.08 14:20
 Allesquarks hat folgendes geschrieben: |
| ich frage mich, wieso ein Rechnung bei der ein ungültiges Ergebnis entsteht überhaupt bei dir auftaucht. |
Er.. Weil er 0 / 0 teilt?^^
Allesquarks - Mi 23.07.08 14:50
Das ist mir auch klar! Mann :?: Ich meinte mehr: Normalerweise nutzt man ein Programm um sinnvolle Sachen zu berechnen. Ich hab die Erfahrung gemacht, dass wenn man den richtigen Algorithmus wählt und sauber programmiert meistens auch solche "Aussetzer" gar nicht erst auftreten. Da er es ja offenbar in einer Schleife laufen lässt, würde ich sagen sind da einfach nur die Grenzen falsch
Xentar - Mi 23.07.08 15:02
Für mich sieht das eher nach nem Rechner für irgendein Spiel aus, um irgendwelche Ressourcenstände zu berechnen oder sowas.
Und da sowas normalerweise vom Anwender händisch eingetippt wird, kann es schon passieren, dass jemand ne 0 einträgt.
Und die Exception "auszumaskieren" oder mit einem try ... except... end; zu unterdrücken, halte ich für ungeschickter, als sie einfach mit einer simplen If-Abfrage gar nicht erst auftreten zu lassen.
Hidden - Mi 23.07.08 16:36
| Allesquarks hat folgendes geschrieben: |
| Das ist mir auch klar! Mann :?: |
Hey, nichts für ungut ;) :beer:
Allesquarks - Mi 23.07.08 18:15
@Hidden: Ja schon gut. Hab mich vlt auch unverständlich ausgedrückt, woltle mich bei meinem Kenntnisstand über des Autors Problem aber auch nicht zu weit aus dem Fenster lehnen. Hättst dir aber auch denken können, dass ich das Problem schon gelesen habe.
@Problem, Xentar: Manchmal macht das durchaus Sinn die Exception zu maskieren. Erstens ist das keine zwingende, sonst könnte man sie nicht maskieren und zweitens stimmt das Ergebnis danach glaube ich sogar formal: nämlich NAN :wink:. Damit kann man nur nicht wirklich gut weiterrechnen und ich denke das hilft ihm nicht, sondern er sollte das rauspatchen oder die Schleife so modifizieren, dass das Problem nicht auftritt.
DeadlyAppearance - Fr 25.07.08 20:59
Wie bereits jemand sagte, kann man es meist mit sauberer Programmierung lösen.
Habe damals eine while Schleife etc. gehabt.
Nun habe ich eine Gleichung mit 2 unbekannten aufgestellt, welche einmal die while-Schleife erspart sowie keine 0 zurückliefert.
Trotzdem war/wäre es halt interessant gewesen, ob es außer if etwas gibt.
Hidden - Fr 25.07.08 22:33
Hi,
Was hätte es denn außer 'if' geben sollen :?: Welches Ergebnis sollte denn bei 0/0 verarbeitet werden? 0/0 ist nunmal rein Mathematisch nicht definiert. Somit bräuchtest du gezwungenermaßen eine Sonderfallbehandlung.
Was du nun machst - da kann man noch sehen: imho betrachtest du es einfach als Null, das ist von der menschlichen Betrachtungsweise her einfach sm logischsten(if Titan = 0 then Verhaeltnis := 0;).
Edit: In den meißten Fälle sieht die Lösung zwar sowieso in der Art aus; die Exception an dieser Stelle dient dazu, dass sich der Programmierer bewusst ist, was passiert. Ansonsten könnte man sich unlogisches Verhalten manchmal nicht erklären.
Man stelle sich nur einmal so etwas vor: Das Ergebnis steigt mit sinkendem Titan immer weiter an, bis es bei 0 spontan auf 0 fällt.
Edit2: limes-Ausdruck in verständlcihen Satz gewandelt :mrgreen: Ich weiß, eig. war alles geklärt und ich hätte mir das hier sparen können.. Aber wo ich es schonmal geschrieben hatte, wollte cih es schon richtig machen :)
mfG,
walter_b - Mi 30.07.08 14:02
| DeadlyAppearance hat folgendes geschrieben: |
Weil ich ca. 6 mal solch eine Rechnung in einer Schleife habe.
Dachte einmal aus Performancegründen kann es nicht schlecht sein 6 ifs zu sparen und mich interessiert es einfach, ob es einen anderen Lösungsweg gibt. |
Ich weiss, dass dies eigentlich schon gelöst ist, aber auch ich will noch meinen Senf dazu geben... Mit Performance und ähnlichen Sachen hatte ich in letzter Zeit sehr viel zu tun. Bei mir wird eine if-Schleife 20 Millionen Mal aufgerufen, und der Performanceverlust, der dadurch entsteht, ist sehr gering. Bei 6 wirst du dies nicht mal spüren, ob da wirklich ein If drin ist oder nicht.
alzaimar - Mi 30.07.08 14:06
| walter_b hat folgendes geschrieben: |
| Bei mir wird eine if-Schleife... |
Ich habe noch nie(!) eine IF-
Schleife in freier Wildbahn gesehen. Kannst Du mir zeigen, wie die aussieht? :wink: For-, While- und Repeat-Schleifen kenne ich, aber eine If-Schleife nicht.
alzaimar - Mi 30.07.08 14:27
Mit einem Link auf die Seite würde wenigstens die Seite eine IF-Schleife sein...
Tilman - Mi 30.07.08 14:43
Wobei ich finde, der Satz müsste eigentlich heißen "Es gibt keine If-Schleifen, sondern nur If-Blöcke". Denn Anfänger verwechseln Schleife mit Block:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
| for a := 1 to 100 do
begin
end;
if (bedingung) then
begin
end; |
alzaimar - Mi 30.07.08 14:46
Das wäre der 'Then'-Block, als Alternative zum 'Else'-Block. If-Abfrage ist schon richtig.
Tilman - Mi 30.07.08 14:48
| alzaimar hat folgendes geschrieben: |
| Das wäre der 'Then'-Block, als Alternative zum 'Else'-Block. If-Abfrage ist schon richtig. |
Wie auch immer - die Anfänger halten jedenfalls
begin
end
bzw.
{
}
für die Schleife, das ist ja ganz offensichtlich. Es sind aber Blöcke.
(übrigens sehe ich das so dass If-Block dem Then-Block entspricht).
walter_b - Mi 30.07.08 16:03
| alzaimar hat folgendes geschrieben: |
| walter_b hat folgendes geschrieben: | | Bei mir wird eine if-Schleife... |
Ich habe noch nie(!) eine IF-Schleife in freier Wildbahn gesehen. Kannst Du mir zeigen, wie die aussieht? :wink: For-, While- und Repeat-Schleifen kenne ich, aber eine If-Schleife nicht. |
:autsch: Ich war mit meinen Gedanken wohl gerade wo ganz anders :roll: Aber was ich sagen wollte, war hoffentlich verständlich...
alzaimar - Mi 30.07.08 16:08
Oooch, die 'If-Schleife' ist nur so ein running gag in der Delphi-Praxis... nix Besonderes. Deine aussage war aber -denke ich- hilfreich, das If-Abfragen neben Floating Point oder (wie bei Dir) String-Operationen nicht weh tun. Bei Integer-Ops oder PChar scans jedoch sehr wohl. Ich habe einige sehr schnelle String-Matching Algorithmen untersucht, und da entscheidet ein einziges IF in der Schleife über Sieg oder Niederlage (performancetechnisch).
delfiphan - Mi 30.07.08 19:15
Du kannst beim Coprozessor (FPU) die Exception ausschalten. Dann erhältst du +Inf, -Inf oder NaN als Ergebnis, je nach Fall. Ob das dein Problem löst, kann ich nicht beurteilen. Jedenfalls "rappelt" es nicht mehr.
Delphi-Quelltext
1:
| SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, exUnderflow, exPrecision]); |
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!