Warum kommt bei Gleitkommadivision durch 0 eine Exception?

[Sherlock]

Wenn ich in C# ein float durch 0 teile erhalte ich Infinity. Gemäß IEEE 754, ein Standard an den sich MS erklärtermaßen hält, ist das auch das erwartete Ergebnis. Bei Delphi erhalten wir (gemäß Schulmathematik erwartungskonform "das gibt es nicht") eine Exception. Ich kann beiden Standpunkten folgen, denn schließlich ist 0,000000000000000000000000001 praktisch 0 aber 1/0,000000000000000000000000001 ist eine richtig große Zahl, warum dann nicht 1/0 als unendlich ausgeben?

Wie seht Ihr das Verhalten? Macht es die Arbeit in C# zB leichter oder schwerer? Vermisst Ihr das Verhalten in ObjectPascal?

Sherlock

[ConnorMcLeod]

Im Ernst?
Na gut: mir ist die Exception lieber, weil ich unmißverständlich darauf gestoßen werde, daß ich eine ungültige Situation habe, die es zu klären gilt. Andernfalls käme es zu verfälschten Ergebnissen.

[Bernhard Geyer]

Das wird über die ExceptionMask gesteuert.
D.h. du kannst das C#-Verhalten damit auch in Delphi bekommen.
Delphi lässt diese Maske unverändert, C# wird es (vermutlich wegen DirectDraw und Co.) Standardmäßig auf "schmeiß keine Exception" setzen.

[himitsu]

Jupp, auch in Delphi kennen die Floats (Single/Double/Extendet) solche Zustände,
aber, wie bereits genannt, wir das nicht standardmäßig als "Fehlerwert" gesetzt, sondern löst die Fehlerbehandlung aus.

Infinity
NegInfinity
NaN

[p80286]

solange ich nicht "Unendlich" erwarte, ist mir die Exception lieber.
(irgendein Wert ist 0 geworden und ich hab nicht daran gedacht)

Gruß
K-H

[Fritzew]

Mir sind Exceptions auch lieber, dann kann man da wo das Problem auftritt auch darauf reagieren.
INFINITE oder auch NAN verschleppen das Problem meiner Meinung nach nur an eine andere Stelle.
Das ganze wird dann lustig wenn man in einer mixed Umgebung arbeitet, sprich eventuell Dlls aus anderen Sprachen einsetzt.
Da kann es schon mal passieren das die Dll das Controlword der FPU ändert. Ganz spassig ist, das in der RTL die FPU Funktionen
nicht Threadsave sind. Wir haben hier schon die tollsten Sachen gesehen. Da gibt es seit Jahren QC's dazu.

[Jens01]

Zitat:

Mir sind Exceptions auch lieber,...

Das kommt sicher auf die Situation an. Bei mir habe ich es in einigen Situationen so, dass Inf für mich eine Ergebnis ist, mit dem ich weiterarbeiten kann.

[Der schöne Günther]

Delphi weicht hier, wie so oft, vom Standard ab. In vielen Anwendungen haben wir die FPU-Exceptions abgeschaltet.

Windows:

Zitat:

By default, the system has all FP exceptions turned off. Therefore, computations result in NAN or INFINITY, rather than an exception.

(Quelle)

GNU C:

Zitat:

By default the exception is simply noted in the floating-point status word, and the program continues as if nothing had happened. The operation produces a default value, which depends on the exception [...]

(Quelle)

IEE 754 höchstselbst:

Zitat:

The 754 model encourages robust programs. It is intended not only for numerical analysts but also for spreadsheet users, database systems, or even coffee pots. The propagation rules for NaNs and infinities allow inconsequential exceptions to vanish. Similarly, gradual underflow maintains error properties over a precision's range.

When exceptional situations need attention, they can be examined immediately via traps or at a convenient time via status flags. Traps can be used to stop a program, but unrecoverable situations are extremely rare.

(Quelle)

Und:

Zitat:

IEEE 754 specifies trapping as an optional feature, required to be off by default, which
has been interpreted by C99 and Java to mean that IEEE 754 deprecates trapping as a
method of diagnosing errors.

(Quelle)

Auch in letzter Zeit sind "neuere" Sprachen wie Java und C# genau diesen Weg gegangen. Nur Delphi ist da wieder anders.

[himitsu]

Zitat:

In der Mathematik ist das Ergebnis der Division durch Null nicht definiert.

So heißt ja erstmal die Grundaussage, somit macht es Delphi doch eigentlich ein bissl richtiger, als C# ?

Zitat:

Wenn ich in C# ein float durch 0 teile erhalte ich Infinity.

Dann läuft aber was falsch, wenn immer Infinity bei dir raus kommt.

+x \ 0 = Infinity
-x \ 0 = NegInfinity
0 \ 0 = NaN

0 durch x ist zwar "immer" 0, aber da das Ergebnis von x durch 0 nicht definiert ist, bleibt nur noch NaN.
Da x durch einen immer kleineren Wert gegen ±Unendlich strebt, hat man sich hier als "Sonderlösung" für Unendlich entschieden,
auch wenn es eigentlich kein definierter Wert ist, und wenn C# und Viele Andere sich nun standardmäßig für diese Lösung entscheideen, dann kann man davon halten, was man will.


https://de.wikipedia.org/wiki/Divisi...ion_durch_null