Power funktioniert nicht wie gedacht

[DieDolly]

Ich möchte gerne Byte in MB, GB usw umrechnen. In einer Variablen steht drin, wie oft *1024 gerechnet werden muss. Da dachte ich kann ich doch gut Power nutzen

Delphi-Quellcode:

var I: Integer;

I := Power(1024, 3); // I := (1024 * 1024 * 1024)

Der Fehlter lautet Inkompatible Typen: 'Integer' und 'Extended'
Wie bekomme ich diesen Fehler weg? Oder gibt es eine andere Möglichkeit um die Schreibweise (1024 * 1024 * 1024) zu verkürzen.

[DeddyH]

Wenn ich mich recht entsinne gibt es für ganze Zahlen Intpower.

[DieDolly]

Dann bekomme ich
Inkompatible Typen: 'Integer' und 'Single'

[MEissing]

Power erwartet als Eingangsparameter Single, Double oder Extended und liefert auch Single, Double oder Extended zurück

[gammatester]

Zitat:

Zitat von DieDolly (Beitrag 1408521)

Ich möchte gerne Byte in MB, GB usw umrechnen. In einer Variablen steht drin, wie oft *1024 gerechnet werden muss. Da dachte ich kann ich doch gut Power nutzen

Delphi-Quellcode:

var I: Integer;

I := Power(1024, 3); // I := (1024 * 1024 * 1024)

Der Fehlter lautet Inkompatible Typen: 'Integer' und 'Extended'
Wie bekomme ich diesen Fehler weg? Oder gibt es eine andere Möglichkeit um die Schreibweise (1024 * 1024 * 1024) zu verkürzen.

Delphi-Quellcode:

var X: Double;

X := Power(Double(1024), 3); // X := (1024 * 1024 * 1024)

[MEissing]

IntPower hat nix mit Integer zu tun :-)

[DeddyH]

Hab ich auch gerade nachgelesen:mrgreen:

[DieDolly]

Wenn ich Doubvle verwende bekomme ich an anderen Stellen Probleme wo ich Integer-Variablen verwende.

Was ist denn hiermit?

Delphi-Quellcode:

I := Round(Power(1024, 3));

[gammatester]

Zitat:

Zitat von DieDolly (Beitrag 1408528)

Wenn ich Doubvle verwende bekomme ich an anderen Stellen Probleme wo ich Integer-Variablen verwende.

Was ist denn hiermit?

Delphi-Quellcode:

I := Round(Power(1024, 3));

Das Ergebnis ist zu groß für integer. Gibt 0 weil Overflow für 32-Bit-Integer.

Delphi-Quellcode:

var I: Int64;
I := Round(Power(1024, 3));

geht aber.

[DieDolly]

Funktioniert sehr gut. Mit Int64 sollte ich eigentlich keine Grenzen sprengen können.

[gammatester]

Zitat:

Zitat von DieDolly (Beitrag 1408530)

Funktioniert sehr gut. Mit Int64 sollte ich eigentlich keine Grenzen sprengen können.

Sorry, integer funktioniert knapp auch (benutzt 30 der 31 Bits). Habe mit 4096 getestet. Aber int64 ist sicherer.

[DieDolly]

Ich bin mir unsicher aber ich glaube

Delphi-Quellcode:

I := Round(System.Math.Power(1024, 7))

funktioniert nicht, selbst wenn I Int64 ist.
Der Fehler lautet

Zitat:

Exception der Klasse $C0000090 mit der Meldung 'floating point invalid operation at 0x004075ff' aufgetreten.

[gammatester]

Zitat:

Zitat von DieDolly (Beitrag 1408532)

Ich bin mir unsicher aber ich glaube

Delphi-Quellcode:

I := Round(System.Math.Power(1024, 7))

funktioniert nicht, selbst wenn I Int64 ist.
Der Fehler lautet

Zitat:

Exception der Klasse $C0000090 mit der Meldung 'floating point invalid operation at 0x004075ff' aufgetreten.

Richtig. 1024=2^10 also 1024^7 = 2^70 und das maximale int64 is 2^63-1. Hier wirst Du nicht um Fließkomma herumkommen, am besten Double.

[DeddyH]

Naja, grob überschlagen müsste 1024^7 eine Zahl mit 21 Stellen ergeben, das ist schon mächtig groß.

[DieDolly]

Würde ein Hardcast auf Int64 die Zahl verkleinern und keinen Fehler mehr erzeugen?

Schematisch

Delphi-Quellcode:

I := Int64(1024^7);

[Michael II]

Nützt nix. Wie bereits weiter oben erwähnt werden Werte vom Typ int64 in 64 Bits gespeichert.

1024(10) = 10000000000(2) (eine 1 mit 10 Nullen)
1024^2(10) = 100000000000000000000(2) (eine 1 mit 20 Nullen)
1024^3(10) = 1000000000000000000000000000000(2) (eine 1 mit 30 Nullen)
...
1024^7(10) ergibt binär eine 1 mit 70 Nullen, also eine 71 stellige binäre Zahl.

ABER: Die grösste positive Zahl, welche du mit einem int64 speichern kannst ist 63 stellig:
1111...….11111(2) (63 1er) = 2^63-1 (10).

D.h. : Du kannst die 1024^7 nicht in einen int64 quetschen ;-).

[gammatester]

Zitat:

Zitat von DieDolly (Beitrag 1408535)

Würde ein Hardcast auf Int64 die Zahl verkleinern und keinen Fehler mehr erzeugen?

Schematisch

Delphi-Quellcode:

I := Int64(1024^7);

1024^7 ist als Operation nicht definiert. power(1024,7) Fließkomma und ein Hardcast nicht erlaubt. Es bleiben zwei unsinnige Konstruktionen

Delphi-Quellcode:

uses system.math;
var
  x: double;
  I: int64 absolute x;
begin
  x := power(double(1024),7);
  writeln('I absolute: ', I);
  {$r-,q-}
  I := 1024*1024*1024;
  I := I*1024*1024;
  I := I*1024*1024;
  writeln('I als Produkt ', I);
end.

Das ergibt dann die falschen Werte

Code:

I absolute: 4922434392715952128
I als Produkt 0

[Daniel]

Wenn du bereit bist, die Zahl künstlich durch ein Typecast zu verringern, welche qualitativen Ansprüche stellst du denn an die in deinem ersten Beitrag erwähnte Umrechnung? Das widerspricht sich doch…

[p80286]

Naja, Ihm fehlte in dem Moment die Erinnerung an das Rechnen mit Potenzen.
Kann schon mal vorkommen.

gruß
K-H

[DieDolly]

Vielleicht helfe ich euch und auch mir, wenn ich mein Problem erkläre.
Ich habe ein TEdit sowie eine TComboBox. Im Edit kann ich eine Zahl eingeben und in der ComboBox kann ich von Byte bis Gigabyte alles auswählen.
Die eingegebene Zahl soll später in das umgerechnet werden, was ich in der ComboBox ausgewählt habe. Das schaffe ich. Aber wie außer mit try except fange ich Fehleingaben ab, sodass die Zahl niemals größer wird als 1099511627775 Bytes (1TB-1Byte)

[gammatester]

Zitat:

Zitat von DieDolly (Beitrag 1408547)

Vielleicht helfe ich euch und auch mir, wenn ich mein Problem erkläre.
Ich habe ein TEdit sowie eine TComboBox. Im Edit kann ich eine Zahl eingeben und in der ComboBox kann ich von Byte bis Gigabyte alles auswählen.
Die eingegebene Zahl soll später in das umgerechnet werden, was ich in der ComboBox ausgewählt habe. Das schaffe ich. Aber wie außer mit try except fange ich Fehleingaben ab, sodass die Zahl niemals größer wird als 1099511627775 Bytes (1TB-1Byte)

Punkt1: Wieso kannst Du kein Double oder Extended nehmen? Punkt 2: Wie schon mehrfach vorgerechnet, passen 70 Bits weder in ein 64-Bit-Integer, noch ohne ein paar Bit Genauigkeitsverlust in ein Fließkomma mit 53- oder 64-Bit Mantisse. Du könntest natürlich Multi-Präzisions-Integer verwenden, aber ich halte das für Overkill.

[DieDolly]

So sieht mein Versuch aus. Alles was über 1 TiB hinaus geht, kann ich verwerfen.

Delphi-Quellcode:

function CalculateSize(Bytes, Multiplier: Int64): UInt64;
const
 MaxSize: Int64 = 1099511627776; // 1 TiB
var
 dTmp: Double;
begin
 if Multiplier > 0 then
  dTmp := System.Math.Power(1024, Multiplier)
 else
  dTmp := 1;

 dTmp := Bytes * dTmp;

 if dTmp > MaxSize then
  dTmp := MaxSize;

 Result := Round(dTmp); // Round um von Double auf Int64 zu kommen [ob Round oder Trunc ist ja egal]
end;

CalculateSize übergebe ich beispielsweise 305 und 2 übergebe, bekomme ich als Ergebnis 305 MiB.
Alles was über 1 TiB geht wird verworfen.

Das macht genau das was ich brauche.

[gammatester]

Ich frage jetzt zu letzen Mal: Warum kannst Du kein Double oder Extended verwenden?

Delphi-Quellcode:

function CalculateSize(Bytes, Multiplier: Int64): Double;

Die Genauigkeit hast Du eh schon verloren, Du hast als Ergebnis ja max 53 signifikante Mantissa-Bits, es geht jetzt nur noch darum, keinen Integer-Overflow zu erhalten.

[DieDolly]

Weil die Funktion der ich das Ergebnis übergebe Int64 erwartet.
Das Ergebnis darf maximal so groß sein wie die maximale Dateigröße unter NTFS. Also 16 TiB.

[THY4243]

Zitat:

Zitat von DieDolly (Beitrag 1408547)

Vielleicht helfe ich euch und auch mir, wenn ich mein Problem erkläre.
Ich habe ein TEdit sowie eine TComboBox. Im Edit kann ich eine Zahl eingeben und in der ComboBox kann ich von Byte bis Gigabyte alles auswählen.
Die eingegebene Zahl soll später in das umgerechnet werden, was ich in der ComboBox ausgewählt habe. Das schaffe ich. Aber wie außer mit try except fange ich Fehleingaben ab, sodass die Zahl niemals größer wird als 1099511627775 Bytes (1TB-1Byte)

Deine Erklärung geht in eine zweite Richtung (neben dem mathemat. Thema)? Wenn es um das "Abfangen" geht, müsstest Du nach jedem Tastendruck das TEdit-Feld auswerten und auf Gültigkeit in Deinem Sinn berechnen. Das würde mittels der Ereignisse des TEdit gehen.
Da ja auch Buchstaben in TEdit möglich sind ... : https://www.delphipraxis.net/19039-e...rlauben-2.html

[DieDolly]

Ich habe meine Funktion jetzt angepasst. Maximaledateigröße 16 EiB minus 1 KiB. Laut Wikipedia die größte zulässige Dateigröße unter NTFS.
Die Funktion funktioniert soweit ganz gut und macht genau was ich brauche.

Delphi-Quellcode:

function CalculateSize(Bytes, Multiplier: UInt64): UInt64;
const
 MaxSize: UInt64 = 18446744073709551615 - 1024; // 16 EiB - 1 KiB
var
 dTmp: Double;
begin
 if Multiplier > 0 then
  dTmp := System.Math.Power(1024, Multiplier)
 else
  dTmp := 1;

 dTmp := Bytes * dTmp;

 if dTmp > MaxSize then
  dTmp := MaxSize;

 Result := Trunc(dTmp);
end;

Einen Integer-Overflow sollte es eigentlich wegen

Delphi-Quellcode:

if dTmp > MaxSize then dTmp := MaxSize;

nicht geben.
Statt Round, was Int64 erwartet, nehme ich jetzt Trunc. Damit sollte alles normalisiert werden.

Ok einen Overflow bekomme ich mit Round und Trunc trotzdem noch wenn dTmp = Maxsize ist.

Wenn ich MaxSize auf 1152921504606847000 (1 EiB) verkleinere, ist das Problem erledigt.
So lasse ich das jetzt auch. Denn ich denke niemand wird jemals eine Datei >1 EiB erzeugen. Und wenn, dann sind es Aliens.

[Michael II]

Nicht gut: Durch Umwandlung von uint64 zu double und zurück zu uint64 verlierst du bei grossen Zahlen an Präzision.

Grund: double ist nur auf ca. 15 Stellen (dezimal) präzis während uint64 Werte 19 stellig sein können.

http://docwiki.embarcadero.com/RADStudio/Tokyo/de/Interne_Datenformate_(Delphi)


Beispiele:
9000000000000000512 wird durch Umwandlung in double und zurück zu uint64 zu
9000000000000000000

9000000000000000513 wird zu 9000000000000001024


Wenn du mit uint64 Genauigkeit rechnen willst, dann verzichte auf double.

Deine uint64 Power Funktion könnte so aussehen:

Delphi-Quellcode:

function Power( exp : integer ) : uint64;
begin
  Result := uint64(1) shl (exp*10); // exp in [0..6] check einbauen
end;

[DieDolly]

Das funktioniert perfekt!

Delphi-Quellcode:

function ConvertBytes(Bytes: UInt64; Multiplier: Integer): UInt64;
const
 // When the calculated filesize is bigger than MaxSize, than normalise it to MaxSize.
 // I think nobody (not a "normal" person) would ever create a file bigger than 1 EiB
 MaxSize: UInt64 = 1152921504606847000; // 1 EiB
begin
 if Multiplier> 0 then
  Result := UInt64(1) shl (Multiplier* 10)
 else
  Multiplier:= 1;

 Result := Bytes * Result;

 if Result > MaxSize then
  Result := MaxSize;
end;

[madas]

Zitat:

Zitat von DieDolly (Beitrag 1408521)

Ich möchte gerne Byte in MB, GB usw umrechnen.

Wenn Du Byte in MB bzw. GB umrechnen möchtest, dann frage ich mich, warum Du mit "*" bzw. Potenzen rechnest.

[TigerLilly]

Der Thread ist ein gutes Beispiel für "Wie löse ich anstelle meines Problems eines, das es gar nicht gibt, und zwar so, dass es keiner versteht?".

Das zu lösende Problem ist doch, dass es "rundherum" Beschränkungen in den erwarteten Typen gibt. Das sollte gelöst werden.
Wenn das - warum auch immer - nicht geht, dann ist die Aufgabenstellung sinnvoll zu lösen und das Ergebnis auf die Typen brauchbar abzubilden.

Jetzt gibt es eine Lösung, die MaxSize zurückliefert, auch wenn der richtige Wert > MaxSize wäre. Gar nicht gut.

if Multiplier> 0 then
Result := UInt64(1) shl (Multiplier* 10) // Das versteht keiner auf den ersten Blick.
else
Multiplier:= 1; // Das ist Irreführung - wird ja gar nicht mehr verwendet.

Result := Bytes * Result; // Welchen Wert hat Result, wenn Multiplyer 0 ist?

if Result > MaxSize then
Result := MaxSize; // das tut in der Seele weh

[madas]

Zitat:

Zitat von TigerLilly (Beitrag 1408563)

Der Thread ist ein gutes Beispiel für "Wie löse ich anstelle meines Problems eines, das es gar nicht gibt, und zwar so, dass es keiner versteht?".

Das zu lösende Problem ist doch, dass es "rundherum" Beschränkungen in den erwarteten Typen gibt. Das sollte gelöst werden.
Wenn das - warum auch immer - nicht geht, dann ist die Aufgabenstellung sinnvoll zu lösen und das Ergebnis auf die Typen brauchbar abzubilden.

Jetzt gibt es eine Lösung, die MaxSize zurückliefert, auch wenn der richtige Wert > MaxSize wäre. Gar nicht gut.

if Multiplier> 0 then
Result := UInt64(1) shl (Multiplier* 10) // Das versteht keiner auf den ersten Blick.
else
Multiplier:= 1; // Das ist Irreführung - wird ja gar nicht mehr verwendet.

Result := Bytes * Result; // Welchen Wert hat Result, wenn Multiplyer 0 ist?

if Result > MaxSize then
Result := MaxSize; // das tut in der Seele weh

Wenn der Thread Ersteller schreibt er möchte Byte in MB oder GB umrechnen, verstehe ich nicht warum die Ergebnisse dann größer werden sollen. ;)

[DieDolly]

Vielleicht ist es so klarer.

Ich habe einen numerischen Wert und die Zusatzinformation, ob das B, KiB, MiB, GiB oder TiB sein sollen.

Rufe ich meine (umbenannte) Funktion nun so auf, erhalte ich 46080 Bytes.

Delphi-Quellcode:

type
  TFileSizes = (_B, _KiB, _MiB, _GiB, _TiB, _PiB);

Ausgabe := ConvertToBytes(45, _KiB);

Ich speichere also irgendwo auf der Festplatte 45 sowie die Zusatzinfo (Speichergröße) ab statt große Zahlen.

Zitat:

// Welchen Wert hat Result, wenn Multiplyer 0 ist?

Im Beispiel oben wären das 45 (Bytes).

Zitat:

if Result > MaxSize then
Result := MaxSize; // das tut in der Seele weh

Warum sollte man jemals höher als 1 EiB gehen? So große Datenmengen gibt es sicherlich insgesamt. Aber ich habe im privatanwenderbereich noch niemanden gesehen, der eine einzelne Datei hat die so groß ist. Angenommen durch falsche Eingaben hat Result schließlich einen Wert von 1 YiB, dann führt das zu einem Fehler.
Da im im weiteren Verlauf aber zwingend Int64 brauche, kann ich hier keine Fließkommazahlen nutzen.

Zitat:

Result := UInt64(1) shl (Multiplier* 10) // Das versteht keiner auf den ersten Blick.

Das ist dasselbe wie Power(1024, 2).

Zitat:

// das tut in der Seele weh

Hilfe nehme ich sehr gerne an! Ich meine jetzt keine Seelenhilfe oder so sondern programmiertechnisch.

[TigerLilly]

Zitat:

Zitat von DieDolly (Beitrag 1408580)

Zitat:

// Welchen Wert hat Result, wenn Multiplyer 0 ist?

Im Beispiel oben wären das 45 (Bytes).

Ich komme auf 0.

Zitat:

Zitat:

if Result > MaxSize then
Result := MaxSize; // das tut in der Seele weh

Warum sollte man jemals höher als 1 EiB gehen? So große Datenmengen gibt es sicherlich insgesamt. Aber ich habe im privatanwenderbereich noch niemanden gesehen, der eine einzelne Datei hat die so groß ist.

Vor 10 Jahren waren TB für Privatanwender undenkbar, so Dinge ändern sich. Außerdem: Das ist schlechter Stil. Das macht man einfach nicht.

[DieDolly]

Zitat:

Zitat von TigerLilly (Beitrag 1408584)

Zitat:

Zitat von DieDolly (Beitrag 1408580)

Zitat:

// Welchen Wert hat Result, wenn Multiplyer 0 ist?

Im Beispiel oben wären das 45 (Bytes).

Ich komme auf 0.

ddd

Zitat:

Zitat:

if Result > MaxSize then
Result := MaxSize; // das tut in der Seele weh

Warum sollte man jemals höher als 1 EiB gehen? So große Datenmengen gibt es sicherlich insgesamt. Aber ich habe im privatanwenderbereich noch niemanden gesehen, der eine einzelne Datei hat die so groß ist.

Vor 10 Jahren waren TB für Privatanwender undenkbar, so Dinge ändern sich. Außerdem: Das ist schlechter Stil. Das macht man einfach nicht.[/QUOTE]

Wie verhindere ich sonst das angesprochene Problem?

[gammatester]

Warum so kompliziert? Wenn man die UINT64-Beschränkung akzeptiert, kann man zB dies verwenden

Delphi-Quellcode:

function CalculateSize(Bytes, Multiplier: UInt64): UInt64;
var
  i: integer;
begin
  Result := Bytes;
  for i:=1 to Multiplier do Result := Result*1024;
end;

Wenn man R/O-Checks eingeschaltet hat, erhält man eine Überschreitung frei Haus, ansonsten ist noch eine Zeile mehr notwendig. Man kann auch Multiplier beschränken, aber das nützt nicht viel, weil ja Bytes*1024 schon ein Overflow werfen könnte.

[Frickler]

Zitat:

Zitat von TigerLilly (Beitrag 1408584)

Vor 10 Jahren waren TB für Privatanwender undenkbar, so Dinge ändern sich. Außerdem: Das ist schlechter Stil. Das macht man einfach nicht.

Vor 10 Jahren kostete eine 1TB Festplatte ca 100 Euro.

Auch beim 128 Bit Dateisystem ZFS ist die maximale Dateigröße "nur" 16 EiB (weil das genau 2^64 Bytes sind, nehme ich an). Und damit werden wir noch sehr sehr lange auskommen ;)

[TigerLilly]

Zitat:

Zitat von Frickler (Beitrag 1408600)

Zitat:

Zitat von TigerLilly (Beitrag 1408584)

Vor 10 Jahren waren TB für Privatanwender undenkbar, so Dinge ändern sich. Außerdem: Das ist schlechter Stil. Das macht man einfach nicht.

Vor 10 Jahren kostete eine 1TB Festplatte ca 100 Euro.

Die erste TB HD gabs 2007. Aber du hast recht, vor 10 Jahren war 2008 + da werden die Preise wohl so um die 100.- gelegen sein.

Zitat:

Auch beim 128 Bit Dateisystem ZFS ist die maximale Dateigröße "nur" 16 EiB (weil das genau 2^64 Bytes sind, nehme ich an). Und damit werden wir noch sehr sehr lange auskommen ;)

Ja, eh. :roll: Aber zwei Dinge sind sicher:
- Niemand weiß, welche Dateigrößen in 10 Jahren unterstützt(!) werden.
- Code, den du jetzt schreibst, wird in 10 Jahren noch im Einsatz sein.

Also würde ich abraten, so zu coden.

[Jasocul]

Zitat:

Zitat von DieDolly (Beitrag 1408580)

Warum sollte man jemals höher als 1 EiB gehen? So große Datenmengen gibt es sicherlich insgesamt. Aber ich habe im privatanwenderbereich noch niemanden gesehen, der eine einzelne Datei hat die so groß ist. Angenommen durch falsche Eingaben hat Result schließlich einen Wert von 1 YiB, dann führt das zu einem Fehler.
Da im im weiteren Verlauf aber zwingend Int64 brauche, kann ich hier keine Fließkommazahlen nutzen.

Nur, weil du etwas noch nie gesehen hast, heißt das nicht, dass es das nicht gibt oder mal geben kann. Meine erste Festplatte hatte 20 MB. Ich dachte, die bekomme ich niemals voll. Heute müsste ich nur 4 Fotos machen, um die Kapazität zu überschreiten.
Da Daten auch immer mehr in der Cloud gespeichert werden, können die Dateien auch immer größer werden. Kannst du abschätzen, wo die Grenze für Dateigrößen in Zukunft sein wird? Und gehe dabei nicht von Festplatten aus. In Zukunft wird es andere Speichermedien geben, die sicher ein vielfaches an Kapazität haben werden.

Du kannst natürlich von deiner jetzigen Sicht ausgehend, dein Programm erstellen. Aber du solltest den Fall, dass du ein Ergebnis bekommst, dass deine Funktion nicht erwartet, richtig behandeln. Es handelt sich in dem Fall wohl um eine Ausnahme-Situation, sprich Exception.
Aus deiner Sicht sollte diese ja niemals auftreten können, also schadet es auch nicht, wenn du das korrekt behandelst und nicht einfach die Werte, die dir nicht passen änderst.

[DieDolly]

Danke für eure Antworten bisher.

Ich habe eine Funktion die eine Datei in Häppchen zerteilt, deren Größe ich bestimmen kann. Dafür ist die ganze Umrechnung die zuvor erwähnt wurde da.
Meine Teilfunktion nimmt UInt64 entgegen.

Wäre es korrekter wenn ich meine ConvertToBytes so abändere, dass Result maximal High(UInt64) betragen kann?

[freimatz]

Nachdem in Windows eine Datei maximal Int64 gross sein kann sollten double unnötig sein.
(s.a. https://docs.microsoft.com/en-us/win...eattributesexa)

Zitat:

Zitat von gammatester (Beitrag 1408595)

Warum so kompliziert? Wenn man die UINT64-Beschränkung akzeptiert, kann man zB dies verwenden

Delphi-Quellcode:

function CalculateSize(Bytes, Multiplier: UInt64): UInt64;
var
  i: integer;
begin
  Result := Bytes;
  for i:=1 to Multiplier do Result := Result*1024;
end;

Wenn man R/O-Checks eingeschaltet hat, erhält man eine Überschreitung frei Haus, ansonsten ist noch eine Zeile mehr notwendig. Man kann auch Multiplier beschränken, aber das nützt nicht viel, weil ja Bytes*1024 schon ein Overflow werfen könnte.

Danke. Wollte auch was mit Integer vorschlagen (eher mit einer Tabelle).
Bei so etwas wo es nur um Integer geht etwas mit Fließkomma zu verwenden ist einfach nur :roll::shock::cry:
(Vor allem wenn man weiß, dass da intern mit Exponentialfunktion und Logarithmus gearbeitet wird.)