Gleitkommadivision...?

[Meflin]

Hi,
ich habe zahlen in der art:

Code:

16502,62

wenn ich die zahl durch 10 teile, sollte die meines erachtens so aussehen:

Code:

1650,262

wenn ich die allerdings mit dem gleitkomma / teile, kommt das raus:

Code:

0,002...

:shock:
div kann man da ja nicht verwenden!
was ist denn da los?

*MFG*

[Chewie]

Zeig mal deinen Code, das kann ich mir nämlich nicht so recht vorstellen...

[c113plpbr]

Vielleicht isses ja noch so nen dummer delphi-bug, wie dieser:
Wenn man

Code:

var
  r : real;

  r := 1 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1;
  ShowMessage(FloatToStr(r));

das hier sich mal anschaut ... müsste doch logischerweise 0 dabei rauskommen, oder? delphi lässt aber -6,7762635780344E-20 rauskommen ... :roll: ... komischerweise ... :gruebel:

ciao, Philipp

[Meflin]

ok hier ein bisschen code:

Delphi-Quellcode:

function GetPrinterRes(const pobj: TPrinter; Horz: Boolean): integer;
var
   Index: Integer;
begin
   if Horz then
      Index:=LOGPIXELSX
   else
      Index:=LOGPIXELSY;
   Result:=GetDeviceCaps(pobj.Handle, Index);
end;

function ConvertPixelstoMMX(const Value:Integer):Double;
begin
   Result := Value / GetPrinterRes(Printer, True) * mmPerInch;
end;

...

hlplabel.Caption := hlplst.Strings[x];
length := length + roundto(ConvertPixelsToMMX(hlplabel.Width), -2);
length := length / 10;
pllength.Caption := floattostr(length) + ' m';

[ibp]

hast du mal durch 10.0 geteilt?

[Chewie]

Zitat:

Zitat von c113plpbr

Vielleicht isses ja noch so nen dummer delphi-bug, wie dieser:
Wenn man

Code:

var
  r : real;

  r := 1 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1;
  ShowMessage(FloatToStr(r));

das hier sich mal anschaut ... müsste doch logischerweise 0 dabei rauskommen, oder? delphi lässt aber -6,7762635780344E-20 rauskommen ... :roll: ... komischerweise ... :gruebel:

ciao, Philipp

Sowas ist kein "Delphi-Bug", sondern tritt auch in anderen Programmiersprachen auf, da es in der Natur von Fließkommadarstellungen liegt.

@Meflin: Geh mal im Einzelschrittmodus durch und überprüf den Wert von Length, da muss der Knackpunkt liegen, nicht an der Division durch 10!

[Meflin]

das habe ich schon getan, der wert "spinnt" erst nach der teilung!

[Jelly]

Das Problem liegt in der Natur der Fließkommazahlen... Nimm einfach mal als Beispiel den Datentyp Double. Der hat intern eine Speicherstruktur von 8 byte. Mit diesen 8 byte, entsprechend 64 bit, kannst du also maximal 2^64=1,8447*10^19 verschiedene Werte speichern. In der Mathematik lernst du aber natürlich, daß es unendlich viele Elemente aus R gibt... Somit steht also auch klar, daß du im Rechner NIE alle reellen Zahlen darstellen kannst, sondern immer nur mit einer gewissen Genauigkeit... Und diese Ungenauigkeit die du in deinem Rechenbeispiel kriegst, liegt hierdrin begründet.

Gruß

[Meflin]

hm versteh ich nicht wirklich :stupid: die zahl ist ja nicht besonders groß :gruebel: aber die ungenauigkeit dafür riesig. wie könnte cih dann das problem umgehen?

[Chewie]

Zitat:

Zitat von Jelly

Das Problem liegt in der Natur der Fließkommazahlen... Nimm einfach mal als Beispiel den Datentyp Double. Der hat intern eine Speicherstruktur von 8 byte. Mit diesen 8 byte, entsprechend 64 bit, kannst du also maximal 2^64=1,8447*10^19 verschiedene Werte speichern. In der Mathematik lernst du aber natürlich, daß es unendlich viele Elemente aus R gibt... Somit steht also auch klar, daß du im Rechner NIE alle reellen Zahlen darstellen kannst, sondern immer nur mit einer gewissen Genauigkeit... Und diese Ungenauigkeit die du in deinem Rechenbeispiel kriegst, liegt hierdrin begründet.

Gruß

Schon, aber aus 1650 wird nicht 0,02....
Oder waren die Werte aus dem ersten Post falsch? Grundsäzlich gilt auf jeden Fall (da es Fließkomma- und nicht Festkommazahlen sind: je kleiner der Betrag der Zahl, desto kleiner die Abstände zwischen den darstellbaren Zahlen.