Announcement

**Hagen Reddmann** · 27.01.2000, 21:02

Hi Torsten

Du hast recht, aber Double ist kein Real, wenn man einem Double-Wert zur Laufzeit 0.015 eines Extended-Wertes zuweist wird ja auch RICHTIG gerechnet. Mir ist schon klar das bei Float-Zahlen Informationen verloren gehen m�ssen. Was ich als BUG bezeichne ist nicht der Double-Type, sondern das er als Konstante definiert FALSCH gespeichert wird. Ich nehme mal an eine Double-Konstante wird als REAL gespeichert und NICHT als Double.

Gru� Hage

**Torsten Grundke** · 28.01.2000, 09:23

Hallo Hagen,

als Real-Zahl meine ich nicht den Delphi-Typ Real sondern Float-Zahlen.

Tsch��

Torste

**J.Henze** · 28.01.2000, 23:37

Hallo Michael, also ich werden Deine beiden o.g. Zahlen auch noch ausprobieren. Aber wie bereits angedeutet, will ich ja gar nicht kaufm�nnisch runden, da dies in meiner Branche nicht �blich ist.
Gru� J�rge

**Torsten Grundke** · 29.01.2000, 13:52

<html>

<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Microsoft FrontPage Express 2.0">
<title>Normale Seite ohne Titel</title>
</head>

<body bgcolor="#FFFFFF">

Hallo Michael,

eine die Beschreibung des internen Aufbaus von Double-Werten
findest Du unter <a
href="http://www.fh-jena.de/~gmueller/Kurs_halle/pas_ieee.html">http://www.fh-jena.de/~gmueller/Kurs_halle/pas_ieee.html</a>

Dein Problem, z.B. mit dem Wert 0.015 liegt eindeutig beim
Datentyp Double. Die 52-Bit Mantisse reicht zur exakten
Darstellung dieses Wertes nicht aus. Mit dem Datentyp Extended
steht Dir ein gr��erer Wertebereich und ein exaktere
Darstellungsm�glichkeit zur Verf�gung (64-Bit Mantisse). Aber
auch mit Extended k�nnen nicht alle Zahlen exakt dargestellt
werden. Somit ist eine 100%
exakte Rundung ist mit Float-Zahlen unm�glich!.

Die FPU (Floating Point Unit) hat verschiedene Rundungsmodi.
Als Standard wird immer zum n�chstgelegenen Wert gerundet. Sind
beide gleich weit entfernt (z.B. 2.5) wird zum n�chsten
geraden Wert gerundet (bei 2.5 auf
2 und bei 1.5 ebenfalls auf 2!). 

Weitere Modi sind abrunden, aufrunden und abschneiden. Meine
diesbez�gliche Literatur behandelt nur Prozessoren bis zum 486'.
Eventuell gibt es bei den neueren Prozessoren weitere Modi's (z.B.
kaufm�nnisches runden). 

Tsch��

Torsten
</body>
</html&gt

**Torsten Grundke** · 29.01.2000, 20:18

<html>

<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Microsoft FrontPage Express 2.0">
<title>Normale Seite ohne Titel</title>
</head>

<body bgcolor="#FFFFFF">

Hi Hagen,

noch eine kleine Erg�nzung. Deine Aussage "wenn man einem Double-Wert zur Laufzeit 0.015 eines Extended-Wertes zuweist wird ja auch RICHTIG gerechnet" trifft nicht zu. Dazu ein kleines Beispiel in Assembler:

<pre>procedure TForm1.Button1Click(Sender: TObject);
var
a: double;
b: extended;
begin
b := 0.015;
asm
fld tbyte ptr [b] {Inhalt von b in oberste FPU-Register laden}
fstp qword ptr [a] {Inhalt des obersten FPU-Registers der Double-Variable a speichern}
wait
end;
end;</pre>

Wenn Du Dir nach der erfolgten Speicherung die Variable a als
�berwachten Ausdruck im Gleitkommaformat anschaust, steht dann
wieder der von Dir bereits genannte Wert 0.0149...94.

Tsch��

Torsten
</body>
</html&gt

**Torsten Grundke** · 29.01.2000, 21:51

Hallo Michael,

vielleich habe ich ja doch noch eine L�sung f�r Dich. Die function von Carsten habe ich ein klein wenig abgewandelt.

<pre>
Function ru ( value : double; _nachkommastellen : integer ) : double;
Var
m : integer;
i : integer;
const
korrektur: double = 0.50000000000001;
Begin
If _nachkommastellen = 0 Then
result := int (value + korrektur)
Else
Begin
m := 1;
For i := 1 To _nachkommastellen Do
m := m * 10;
result := int(value * m + korrektur) / m;
End;
End;
</pre>

Die Anzahl der Nullen zwischen 5 und 1 habe ich jetzt nur "per Daumen" eingef�gt (sie ist abh�ngig davon, wieviel signifikante Stellen der Wert VALUE max. haben soll.

Auch diese abgewandelte function wird nicht alle Zahlen korrekt runden, solange aber die Anzahl der signifikanten Stellen zumindest im ein- vielleich auch im niedrigen 2stelligen Bereich liegt m��te sie funktionieren.

Tsch��

Torste

**Hagen Reddmann** · 30.01.2000, 14:32

Hi Torsten

Hast'e mal ohne Assembler getestet ? Einfach nur Double = Extended(0.015) ? bei klappts, Ich vermute das dort interne "gerundet" wird ?

Gru� Hage

**Hagen Reddmann** · 30.01.2000, 14:32

Hi Torsten

Hast'e mal ohne Assembler getestet ? Einfach nur Double = Extended(0.015) ? bei mir klappts, Ich vermute das dort interne "gerundet" wird ?

Gru� Hage

**Torsten Grundke** · 30.01.2000, 18:03

Hallo Hagen,

wenn Du als Anzeigentyp Gleitkommawert eingibst bekommst Du den exakten Zahlenwert und der ist nun mal 0.0149...94 bei Double.

Tsch��

Torste

**markus lemcke** · 28.03.2001, 17:14

"jungs jungs" !!!

ihr wolltet nicht zuf�llig ein buch dar�ber schreiben?? 
und welche funktion nimmt man nun am besten???

mfg

marku

**Patrick Sack** · 17.11.2002, 19:12

Hi,
 
 ich will ja kein Querulant sein, aber das �berzeugt mich alles noch nicht.
 Wenn dem so w�re, das dieses Verhalten eine Eigenart von Double Werten
ist, wieso gibt es dann Programmiersprachen, in denen dieses Verhalten nicht
auftritt?
 Bsp.:
 Auf der Basis von Hagens Code aus #13 habe ich folgende zwingende if
bedingung aufgebaut:
<pre>
D := C * 100;
If d = (c*100) then
Writeln('d = (c*100) TRUE')
Else
Writeln('d = (c*100) FALSE');
</pre>
 
 Von der mathematischen Seite her betrachtet sollte immer die If Bedingung
erf�llt werden.
 
 Umgesetzt wurde dieser Code in die folgenden Sprachen:
 1) Delphi 5
 2) Borland Pascal 7
 3) MS Access 97 (Basic)
 4) PHP 4.??
 5) gcc (irgend ein Gnu Compiler auf BeOS 5, leider kenne ich die
Versionsnummer nicht.)
 
 Die Tests in 1 und 2 waren wie schon hier diskutiert negativ.
 Da die Tests in 3 und 4 positiv waren habe ich mich schon fast dazu
hinrei�en lassen zu Behaupten, das sei ein Borland Problem (Ph�nomen). Jedoch
zeigte der Test in 5 auch ein falsches Ergebnis.
 Damit ist das wohl kein Borland Problem.
 Liegt es vieleicht daran das 3 und 4 Interpreter sind?
 Hat man in 3 und 4 den Double Typen nun richtig(er) oder falsch
implementiert?
 Ich hatte jetzt leider kein c# zur Hand. Wenn jemand mal schnell diesen
Code in C# ausf�hren k�nnte w�re ich ihm sehr dankbar.
 In den folgenden Code Beispielen habe ich mich hin und wieder mal darum
gedr�ckt den zweiten If Vergleich zu machen, in dem die Double Werte in Strings
umgewandelt werden und erst dann verglichen werden. Dieses If Statement ist
meiner Meinung nach nicht so gravierend, soll es ja nur im negativen Falle
zeigen, das die Zahlen nach Konvertierung doch gleich sind.
 Es folgen die Code Beispiele

**Patrick Sack** · 17.11.2002, 19:16

Die Code Beispiele:
 Delphi 5
<pre>
program DoubleTest;

{$APPTYPE CONSOLE}

uses

sysutils;

const

C: Double = 0.015;

var

D: Double;

begin

D := C * 100;

If d = (c*100) then

Writeln('d = (c*100) TRUE')

Else

Writeln('d = (c*100) FALSE');

If FloatToStr(d) = FloatTostr((c*100)) then

Writeln('FloatToStr(d) = FloatTostr((c*100)) TRUE')

Else

Writeln('FloatToStr(d) = FloatTostr((c*100)) FALSE');

Writeln('C: ',C);

Writeln('C*100: ',C*100);

Writeln('D: ',D);

Readln;

end.

Ergebnis:

d = (c*100) FALSE

FloatToStr(d) = FloatTostr((c*100)) TRUE

C: 1.50000000000000E-0002

C*100: 1.50000000000000E+0000

D: 1.50000000000000E+0000

</pre>
 
 Borland Pascal 7
<pre>
program DoubleT;

{$N+}

uses crt;

const

C: Double = 0.015;

var

D: Double;

begin

D := C * 100;

If d = (c*100) then

Writeln('d = (c*100) TRUE')

Else

Writeln('d = (c*100) FALSE');

(* If Str(d) = Str((c*100)) then

Writeln('Str(d) = Str((c*100)) TRUE')

Else

Writeln('FloatToStr(d) = FloatTostr((c*100)) FALSE');*)

Writeln('C: ',C);

Writeln('C*100: ',C*100);

Writeln('D: ',D);

Readln;

end.

Ergebnis:

d = (c*100) FALSE

C: 1.50000000000000E-0002

C*100: 1.50000000000000E+0000

D: 1.50000000000000E+0000

</pre>
 
 Access 97
<pre>
Option Compare Database

Option Explicit

Private Const C As Double = 0.015

Public Sub x()

Dim D As Double

D = C * 100

If D = (C * 100) Then

Debug.Print "d = (c*100) TRUE"

Else

Debug.Print "d = (c*100) FALSE"

End If

If Str(D) = Str((C * 100)) Then

Debug.Print "Str(d) = Str((c*100)) TRUE"

Else

Debug.Print "Str(d) = Str((c*100)) FALSE"

End If

Debug.Print "C: " & C

Debug.Print "C*100: " & C * 100

Debug.Print "D: " & D

End Sub

Ergebnis:

d = (c*100) TRUE

Str(d) = Str((c*100)) TRUE

C: 0,015

C*100: 1,5

D: 1,5

</pre>
 
 PHP 4.??
<pre>
$C = 0.015;

$D = $C * 100;

if ($D == ($C*100))

echo 'br $D == ($C*100) TRUE';

else

echo 'br $D == ($C*100) FALSE';

if ((string)$D == (string)($C*100))

echo ' br ((string)$D == (string)($C*100)) TRUE';

else

echo ' br ((string)$D == (string)($C*100)) FALSE';

echo ' br $C: '."$C";

echo ' br $C*100: '.(string)($C*100);

echo ' br $D: '."$D";

Ergebnis:

$D == ($C*100) TRUE

((string)$D == (string)($C*100)) TRUE

$C: 0.015

$C*100: 1.5

$D: 1.5

</pre>
 
 Gnu C Compiler der auf meinem BeOS liegt. Leider wei� ich die Version
nicht.
<pre>
#include stdio.h
main()
{
double C = 0.015;
double D = C * 100;
if (D == (C*100))
printf("D == (C*100) TRUE\n");
else
printf("D == (C*100) FALSE\n");
/* if ((string)D == (string)(C*100))
printf("((string)D == (string)(C*100)) TRUE\n");
else
printf("((string)D == (string)(C*100)) FALSE\n");*/
printf("C: %f\n",C);
printf("C*100: %f\n",(C*100));
printf("D: %f\n",D);
}
Ergebnis:
D == (C*100) FALSE
C: 0.015000
C*100: 1.500000
D: 1.500000
</pre&gt

**Torsten Grundke** · 18.11.2002, 08:36

Hallo Patrick,

meiner Meinung nach ist es in Deinem Testcode sinnvoller die Variable D gleich mit 1.5 zu initialisieren.

Bei den Interpeter-Sprachen vermute ich mal das die intern runden.

Tschau

Torsten

PS: wenn man das Programm einfach mal mit dem Debugger im "Maschinencode" beobachtet und sich die Ergebinsse der FPU anschaut wird einem vieles klarer

**Patrick Sack** · 21.11.2002, 01:50

Hallo Torsten,
 
 >meiner Meinung nach ist es in Deinem Testcode sinnvoller die Variable D gleich mit 1.5 zu initialisieren.
 
 Das habe ich extra gemacht, da ich ja den Compiler etwas unter Stre� setzen wollte.
 
 >Bei den Interpeter-Sprachen vermute ich mal das die intern runden.
 
 Wenn dem so w�re, was ist dann daran verwerflich? Denn rein mathematich gesehen, kommt beim Runden das richtige Ergebnis heraus. Was ist nun falsch? Das Runden (das den Schwachpunkt der FPU beseitigt) oder zu behaupten die Werte w�ren nicht gleich (was ja auch stimmt, da die FPU die Werte nicht korrekt speichert). Was mich interessieren w�rde ist, ob auch die Programmiersprachen die den Test mit 1.5 bestanden haben bei irgend welchen Zahlen ins schleudern kommen.
 
 >...und sich die Ergebinsse der FPU anschaut wird einem vieles klarer.
 
 Die Ergenisse sind unbestreitbar, aber warum gibt es Programmiersprachen die anscheinend nicht daf�r anf�llig sind?
 In C# habe ich es auch mal getestet (siehe Code weiter unten) und hier tritt der Fehler auch nicht auf (ich wahr angenehm �berrascht (ein Pluspunkt f�r C#)).
 (Es w�rde mich sehr interessieren, wie sich das alte Visual C++ verh�lt bei dem Beispiel Code und wie sich der selbe c++ code im .Net Framework verh�lt.)
 Der Typ Double ist in allen Sprachen 64 Bit gro� (ich habe jetzt nur mal in der Delphi, C# und Access Hilfe nachgeschaut (daraus folgere ich das es auch bei den anderen Sprachen so ist)). Damit ist die Voraussetzung gleich, jedoch rechnen die einen so, das "mathematisch" kein Fehler auftritt. Und daraus folgere ich, wenn man es nicht als Bug bezeichnen kann (siehe Hagen), so ist es zumindest nicht mehr zeitgem��.
 
 Sp�testens wenn jemand den nahezu identischen Delphi Code in Delphi.net und Delphi 7 ausf�hrt und unterschiedliche Ergebnisse bekommt wird das ganze sehr fragw�rdig. Ich denke (hoffe), da� das in irgend einer Delphi Version ge�ndert wird.
 
 Aber was kann man nun als L�sung f�r diese Problem anbieten?
 1)
 Wie Hagen schon sagte man k�nnte Extended verwenden. Aber wie sieht es dann mit der Kommunikation mit anderen Komponenten aus?
Was passiert wenn man MYDBField.asFloat := MyExtended; oder umgekehrt schreibt. Wie genau rechnet der IB mit Dialect 3 bei Double Preccision (ist ja auch ein Borland Produkt). Das werde ich mal bei Zeiten testen. (Wenn jemand das zuf�llig wei�, ob es hier ebenfalls zu Problemen kommen kann bitte melden. Dann erspare ich mir Arbeit. (Danke!))) Wie sieht es im Vergleich dazu mit einem MS Server aus?
 2)
 Wenn man Double Werte vergleicht mu� man diese vorher in einen String konvertieren und dann vergleichen (G��hhn).
(Wenn jemand noch eine bessere Idee hat, bitte melden. (Danke!)))
 
 mfg
 P

**Patrick Sack** · 21.11.2002, 01:53

Der C# Code (siehe vorherige Message):
<pre>
using System;

namespace ConsoleApplication1
{
/// <summary>
/// Zusammendfassende Beschreibung f�r Class1.
/// </summary>
class Class1
{
/// <summary>
/// Der Haupteinstiegspunkt f�r die Anwendung.
/// </summary>
[STAThread]
static void Main(string[] args)
{
//
// TODO: F�gen Sie hier Code hinzu, um die Anwendung zu starten
//
double C = 0.015;
double D = C * 100;
if (D == (C*100))
System.Console.Write("D == (C*100) TRUE\n");
else
System.Console.Write("D == (C*100) FALSE\n");
if (Convert.ToString(D) == Convert.ToString(C*100))
System.Console.Write("(Convert.ToString(D) == Convert.ToString(C*100)) TRUE\n");
else
System.Console.Write("(Convert.ToString(D) == Convert.ToString(C*100)) FALSE\n");
System.Console.WriteLine("C: " + Convert.ToString(C));
System.Console.WriteLine("C*100: " + Convert.ToString(C*100));
System.Console.WriteLine("D: " + Convert.ToString(D));
System.Console.ReadLine();
}
}
}

Ergenis:
D == (C*100) TRUE
(Convert.ToString(D) == Convert.ToString(C*100)) TRUE
C: 0,015
C*100: 1,5
D: 1,5
</pre&gt

Announcement

Suche eine allgemein funktionierende Rundungsfunktion

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment