| Autor |
Beitrag |
kiwicht
      
Beiträge: 1021
Win 7, MacOS
Delphi x, VBA, PHP, ...
|
Verfasst: Mo 02.06.03 12:57
Hallo..
es geht um Prozent-Rechnung. Ich hab einen Brutto-Preis, von dem soll ein Rabat-Satz abgezogen werden.
Also: Brutto + Rabatt / 100 ergibt Nettopreis.
So sieht im Moment meine Formel aus:
Delphi-Quelltext 1:
| edPGErgebnis.Text := IntToStr(StrToInt(dbeListpreisV.Text) * StrToInt(edRabattResult.Text) div 100); |
Klappt soweit,ausser wenn die Zahl eine Kommastelle enthält... was mach ich falsch? Integer dürften doch Kommastellen enthalten, oder hab ich irgendwas übersehen?
vielen Dank für eure Hilfe
mfg
|
|
Tweafis
      
Beiträge: 647
WinXP + fbsd
Delphi 5 Prof
|
Verfasst: Mo 02.06.03 13:10
Delphi-Quelltext 1:
| Integer dürften doch Kommastellen enthalten |
Nein!
Mach FloatToStr bzw StrToFloat, oder benutz ein real/double.
lies dir mal die hilfe zu integer bzw. real durch...
_________________ .: Es wird der Tag kommen, an dem wir es nicht mehr ändern können :.
|
|
Keldorn
      
Beiträge: 2266
Erhaltene Danke: 4
Vista
D6 Prof, D 2005 Pro, D2007 Pro, DelphiXE2 Pro
|
Verfasst: Mo 02.06.03 13:12
Hallo
| Zitat: |
Integer dürften doch Kommastellen enthalten,
|
wie kommst du denn auf den Trichter?
Integr sind ganze Zahlen und haben keine Nachkommastellen.
Was du suchst ist STRToFloat und das Inttostr mußt du dann auch in ein z.B. FloattoSTR oder auch FloatTostrF.
edit: zu langsam
Mfg Frank
_________________ Lükes Grundlage der Programmierung: Es wird nicht funktionieren.
(Murphy)
|
|
kiwicht 
      
Beiträge: 1021
Win 7, MacOS
Delphi x, VBA, PHP, ...
|
Verfasst: Mo 02.06.03 13:34
hm, vielen Dank für die Hilfe.... weiß auch nicht, aber ich dachte ganz ehrlich immer, das Integer auch Kommastellen haben.... fragt mich nich wieso.. war wohl ne Bildungs-Lücke..
naja, jedenfalls vielen Dank...
|
|
MaxiTB
      
Beiträge: 679
Win2000, WinXp, Workbench ;-)
D7 Ent, VS2003 Arch.
|
Verfasst: Mo 02.06.03 13:51
Ist ja schlimm ... Integer mit Kommastellen. *g*
Okay - fast noch schlimmer wäre zu behaupten, Spock ist ein Klingone. Das wäre dann wirklich eine Bildungslücke ersten Ranges. 
_________________ Euer Mäxchen
Wer früher stirbt, ist länger tot.
|
|
tommie-lie
      
Beiträge: 4373
Ubuntu 7.10 "Gutsy Gibbon"
|
Verfasst: Mo 02.06.03 14:23
Ähh, und div durch / ersetzen, dann klappt's auch mit dem Fließkomma 
_________________ Your computer is designed to become slower and more unreliable over time, so you have to upgrade. But if you'd like some false hope, I can tell you how to defragment your disk. - Dilbert
|
|
Brueggendiek
      
Beiträge: 304
Win 98, Win98SE, Win XP Home
D5 Std
|
Verfasst: Di 03.06.03 00:15
Hallo!
Mal was zum Klarstellen:
| Keldorn hat folgendes geschrieben: | | Integr sind ganze Zahlen und haben keine Nachkommastellen. |
Das ist so nicht richtig!
Integer sind Festkomma-Zahlen. Die Position des Kommas wird dabei von der Programmlogik vorgegeben und muß bei der Ausgabe berücksichtigt werden.
Man kann so z.B. mit genügend großen Integern Geldbeträge auf 1/100 Cent berechnen. Bei der Ausgabe wird aus 100000 dann 10,00 EUR!
Im Gegensatz dazu sind Real-Zahlen Fließkommawerte, bei denen das Komma enthalten ist.
Wenn immer möglich, sollte man auf Integer zurückgreifen. Diese Werte werden eineindeutig (also umkehrbar eindeutig) auf die internen Bits umgerechnet und sind genau.
Bei Real ist es z.B. unmöglich, 0,2 genau darzustellen! Bei großen Zahlen kann es sein, daß das Hinzuzählen einer kleinen Zahl keine Änderung auslöst.
Der Grund ist, daß bei Real-Zahlen die Ziffernfolge (Mantisse) und ein Exponent gespeichert werden. Dabei stehen nur begrenzt viele Stellen für die Mantisse zur Verfügung.
Die Darstellung im Rechner ist dabei mmmm * 2 hoch eee, die Mantisse ist 0,mmmm!
Vereinfachtes Beispiel:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7:
| var r:real; i:integer; begin r:=10000.0; for 1 := 1 to 10000 do r:=r+1; end; |
Ich nehme mal zur Verdeutlichung eine dezimale Darstellung.
Würde hier r als 0,xxx * 10 hoch ee gespeichert, hätten wir:
10000 ist 0,100 * 10 hoch 5
1 ist 0,1 * 10 hoch 1
Zum Addieren müssen wir die 1 auf die gleich Darstellung bringen wie der andere Wert, also 0,000(01) * 10 hoch 5 - gespeichert als 0, weil ja nur 3 Stellen vorhanden sind.
Damit würde die Schleife zum Ausgangswert von 10000 insgesamt 10000 mal 0 addieren - Ergebnis 10000!!!
Gruß
Dietmar Brüggendiek
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: Di 03.06.03 12:23
| Zitat: | | Integer sind Festkomma-Zahlen. |
Nein! Integer sind ganze Zahlen, da kommt kein Komma drin vor. Festkommadarstellung wird zur Darstellung nicht-ganzer Zahlen verwendet, genau wie die Fließkommadarstellung. Wenn es so wäre, wie Du sagst, könnte ich die Zahl 0,5 (1*2^(-1), in der Festkommadarstellung also darstellbar) in einem Integer speichern.
Außerdem ist auch (bei begrenzter Bitanzahl) die Festkommadarstellung nicht beliebig genau. Das geht nur mit unbegrenzter Anzahl von Bits, die natürlich nicht realisiert werden können. Es ist also durchaus möglich, dass auch Zahlen in der Festkommadarstellung nicht gespeichert werden können.
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
Udontknow
      
Beiträge: 2596
Win7
D2006 WIN32, .NET (C#)
|
Verfasst: Di 03.06.03 16:15
Was Brueggendiek einfach sagen wollte, war, daß man sozusagen Nachkommastellen vortäuschen kann. Man definiert einfach die letzten 2 Ziffern als Nachkommastellen und gibt einen Integer dementsprechend aus, schiebt also einfach ein "," vor die letzten zwei Ziffern. Intern rechnen tut man dann also immer mit dem 100-fachen Wert.
Man muss nur aufpassen, daß man nicht den Wertebereich des Integers verletzt (+- 2 Milliarden und ein paar zerquetschte...).
Nachtrag:
Real stellt zwar unter bestimmten Bedingungen Zahlen falsch dar, dies tritt aber erst bei 16 Stellen Unterschied auf. Damit kann ein Integer wohl kaum mithalten.
Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
| r:=1; for i:=1 to 15 do r:=r*10; for i := 1 to 10000 do r:=r+1; ShowMessage(FloatToStr(r)); r:=1; for i:=1 to 16 do r:=r*10; for i := 1 to 10000 do r:=r+1; ShowMessage(FloatToStr(r)); |
Cu,
Udontknow
Zuletzt bearbeitet von Udontknow am Di 03.06.03 16:26, insgesamt 1-mal bearbeitet
|
|
other
Hält's aus hier
Beiträge: 7
WindowsXP, Windows Vista
Delphi 5, Visual C# Express
|
Verfasst: Di 03.06.03 16:18
| Peter Lustig hat folgendes geschrieben: | | Zitat: | | Integer sind Festkomma-Zahlen. | Nein! Integer sind ganze Zahlen, da kommt kein Komma drin vor.
|
Eigentlich ist der Typ Integer nur eine Untermenge der ganzen Zahlen. Innerhalb dieser Menge ist jede Zahl darstellbar, somit handelt es sich glz. um einen ordinalen Typen (eindeutige Reihenfolge, die durch Ordinalposition angegeben wird).
| Zitat: |
Festkommadarstellung wird zur Darstellung nicht-ganzer Zahlen verwendet, genau wie die Fließkommadarstellung. Wenn es so wäre, wie Du sagst, könnte ich die Zahl 0,5 (1*2^(-1), in der Festkommadarstellung also darstellbar) in einem Integer speichern.
|
In einem Ganzzahltypen ist dieser Wert nicht darstellbar, aber in einem Festkommatypen wie dem Typ Currency
| Zitat: |
Außerdem ist auch (bei begrenzter Bitanzahl) die Festkommadarstellung nicht beliebig genau. Das geht nur mit unbegrenzter Anzahl von Bits, die natürlich nicht realisiert werden können. Es ist also durchaus möglich, dass auch Zahlen in der Festkommadarstellung nicht gespeichert werden können. |
Nur, wenn diese Zahlen nicht in der Menge des Datentyps vorhanden sind oder die Anzahl der Stellen die maximale Anzahl der Stellen des Typs übersteigt.
MfG Other.
_________________ Ein Forum ist ein Platz unbezahlter Arbeit.
|
|
Udontknow
      
Beiträge: 2596
Win7
D2006 WIN32, .NET (C#)
|
Verfasst: Di 03.06.03 16:29
Hier mal die Übersicht aus der Delphi-Hilfe:
Quelltext 1: 2: 3: 4: 5: 6: 7:
| Typ Bereich Signifikante Stellen Größe in Byte Real48 2.9 x 10^-39 .. 1.7 x 10^38 11-12 6 Single 1.5 x 10^-45 .. 3.4 x 10^38 7-8 4 Double 5.0 x 10^-324 .. 1.7 x 10^308 15-16 8 Extended 3.6 x 10^-4951 .. 1.1 x 10^4932 19-20 10 Comp -2^63+1 .. 2^63 -1 19-20 8 Currency -922337203685477.5808.. |
Currency ist übrigens genau so ein "missbrauchter" Integer-Typ (intern ein Int64).
Cu,
Udontknow
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: Di 03.06.03 16:31
@Udontknow: wenn Brueggendiek schreibt, Integer wären Festkommazahlen, dann hört sich das für mich irgendwie anders an ...
@other:
| Zitat: | | Eigentlich ist der Typ Integer nur eine Untermenge der ganzen Zahlen. |
Ich habe nichts anderes geschrieben. Ich habe ja geschrieben, dass Integer ganze Zahlen sind und nicht, dass ganze Zahlen Integer sind!
| Zitat: | | In einem Ganzzahltypen ist dieser Wert nicht darstellbar, ... |
Exakt das war der Punkt, den ich zum Audruck bringen wollte!
| Zitat: | | Nur, wenn diese Zahlen nicht in der Menge des Datentyps vorhanden sind oder die Anzahl der Stellen die maximale Anzahl der Stellen des Typs übersteigt. |
Kein Widerspruch. Deswegen auch das Wörtchen "möglich".
Übrigens sind beide Teile Deiner Aussage identisch. Denn eine zu geringe Anzahl an Stellen heißt ja nur, dass die Menge der darstellbaren Zahlen "Löcher" aufweist, also zerrissen ist. Wenn also die Anzahl der Stellen die maximale Anzahl der darstellbaren Stellen übersteigt, ist sie genauso nicht Teil der Zahlenmenge des Datentyps, wie wenn die Zahl zu groß ist.
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: Di 03.06.03 16:35
nochmal @Udontknow:
Auszug aus "Delphi in a Nutshell":
| Zitat: | | The Currency type employs the floating-point processor, using 64bits of precision in two's complement form. Because Currency is a floating-point type, you cannot use any integer operators (such as a bit shifting or masking) |
ist also kein Int64
P.S.: Das Buch ist von 2000, kann also sein, dass es jetzt anders ist!
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
Udontknow
      
Beiträge: 2596
Win7
D2006 WIN32, .NET (C#)
|
Verfasst: Di 03.06.03 16:51
Ist offiziell keiner, intern schon.
Auch aus der Delphi-Hilfe:
| Zitat: | | Der Typ Currency ist ein Festkomma-Datentyp, der Rundungsfehler in finanzmathematischen Berechnungen minimiert. Er wird als skalierter 64-Bit-Integer gespeichert, bei dem die vier niedrigst wertigen Stellen implizit vier Nachkommastellen repräsentieren. Bei einer Kombination mit anderen reellen Typen in Zuweisungen und Ausdrücken werden Currency-Werte automatisch mit 10000 multipliziert. |
Cu,
Udontknow
|
|
other
Hält's aus hier
Beiträge: 7
WindowsXP, Windows Vista
Delphi 5, Visual C# Express
|
Verfasst: Di 03.06.03 17:00
Hallo,
| Zitat: |
@other:
| Zitat: | | Eigentlich ist der Typ Integer nur eine Untermenge der ganzen Zahlen. | Ich habe nichts anderes geschrieben. Ich habe ja geschrieben, dass Integer ganze Zahlen sind und nicht, dass ganze Zahlen Integer sind! |
Ich glaube, da habe ich dich falsch verstanden. Bei dem Wort Integer beziehst du dich direkt auf die Ganzzahlen, ich jedoch auf den Typen.
Der Typ Integer ist eine Untermenge der ganzen Zahlen, während Integer ganze Zahlen sind.
| Zitat: | | Übrigens sind beide Teile Deiner Aussage identisch. Denn eine zu geringe Anzahl an Stellen heißt ja nur, dass die Menge der darstellbaren Zahlen "Löcher" aufweist, also zerrissen ist. Wenn also die Anzahl der Stellen die maximale Anzahl der darstellbaren Stellen übersteigt, ist sie genauso nicht Teil der Zahlenmenge des Datentyps, wie wenn die Zahl zu groß ist. |
Eigentlich wäre es dann gar keine Menge mehr, oder? Ein Zahlentyp kann IMHO nur durch eine Menge repräsentiert werden, wenn es ein ordinaler Zahlentyp ist. Damit fallen Gleitkommazahlen aus der Reihe.
MfG Other.
_________________ Ein Forum ist ein Platz unbezahlter Arbeit.
|
|
other
Hält's aus hier
Beiträge: 7
WindowsXP, Windows Vista
Delphi 5, Visual C# Express
|
Verfasst: Di 03.06.03 17:02
Hallo,
| Peter Lustig hat folgendes geschrieben: | nochmal @Udontknow:
Auszug aus "Delphi in a Nutshell":
| Zitat: | | The Currency type employs the floating-point processor, using 64bits of precision in two's complement form. Because Currency is a floating-point type, you cannot use any integer operators (such as a bit shifting or masking) |
ist also kein Int64
P.S.: Das Buch ist von 2000, kann also sein, dass es jetzt anders ist! |
Klingt nach Comp.
MfG Other.
_________________ Ein Forum ist ein Platz unbezahlter Arbeit.
|
|
Udontknow
      
Beiträge: 2596
Win7
D2006 WIN32, .NET (C#)
|
Verfasst: Di 03.06.03 17:06
| other hat folgendes geschrieben: |
Eigentlich wäre es dann gar keine Menge mehr, oder? Ein Zahlentyp kann IMHO nur durch eine Menge repräsentiert werden, wenn es ein ordinaler Zahlentyp ist. Damit fallen Gleitkommazahlen aus der Reihe. |
Was bitte schön ist denn dann die Menge der reellen Zahlen?
Umgekehrt macht es mehr Sinn: Ein Zahlentyp (wir sprechen jetzt von Speicherformen auf dem PC) kann nur Mengen darstellen, deren Anzahl Elemente begrenzt ist.
Bei Integerwerten ist dies durch Überlauf bzw. Unterlauf gegeben, bei den Fliesskomma-Typen spielt zusätzlich noch die durch die Anzahl der signifikanten Stellen bestimmten Granularität eine Rolle.
Cu,
Udontknow
|
|
other
Hält's aus hier
Beiträge: 7
WindowsXP, Windows Vista
Delphi 5, Visual C# Express
|
Verfasst: Di 03.06.03 18:18
Hallo,
| Udontknow hat folgendes geschrieben: | | other hat folgendes geschrieben: |
Eigentlich wäre es dann gar keine Menge mehr, oder? Ein Zahlentyp kann IMHO nur durch eine Menge repräsentiert werden, wenn es ein ordinaler Zahlentyp ist. Damit fallen Gleitkommazahlen aus der Reihe. |
Was bitte schön ist denn dann die Menge der reellen Zahlen?
|
Etwas Böses  .
Nein, ich habe den Begriff Menge total falsch definiert. Habe mal mein altes Mathebuch rausgekrammt und geschmökert.
| Zitat: |
Umgekehrt macht es mehr Sinn: Ein Zahlentyp (wir sprechen jetzt von Speicherformen auf dem PC) kann nur Mengen darstellen, deren Anzahl Elemente begrenzt ist.
|
Jupp.
| Zitat: |
Bei Integerwerten ist dies durch Überlauf bzw. Unterlauf gegeben,
|
Jupp.
| Zitat: |
bei den Fliesskomma-Typen spielt zusätzlich noch die durch die Anzahl der signifikanten Stellen bestimmten Granularität eine Rolle.
|
Genauer gesagt durch die nicht unendlich vorhanden Mantissen- und Exponentenbits, schließlich ist es auch mit reellen Typen nicht möglich, alle Zahlen innerhalb eines Teilbereichs darzustellen, selbst wenn diese Zahlen innerhalb des Wertebereichs liegen und die maximale Anzahl der Stellen dieser Gleitkommazahl die maximale Anzahl Stellen des Typs nicht überschreitet.
MfG Other.
_________________ Ein Forum ist ein Platz unbezahlter Arbeit.
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: Di 03.06.03 18:19
Kaum geht man mal ein bisschen Einkaufen, schon muss man Massen an Postings beantworten!
(1) beim Currency gebe ich mich geschlagen. Die Delphi-Hilfe wird's wissen.
(2) | other hat folgendes geschrieben: | | Der Typ Integer ist eine Untermenge der ganzen Zahlen, während Integer ganze Zahlen sind. |
Ja, genauso meinte ich das auch!
(3) | other hat folgendes geschrieben: | | Klingt nach Comp. |
Nach was?
(4) zu den Mengen mit Löchern: stell Dir mal den Zahlenstrahl vor und da darauf die rationalen Zahlen Q. Q ist dann definiert als Q := {k / n | k € Z, n € Z\{0}} wobei das Eurozeichen mal für das "Element-aus-Zeichen" herhalten musste und Z natürlich alle ganzen Zahlen sind. (ich glaube, die Def. ist nicht ganz korrekt, weil einiges doppelt vorkommt, aber sie reicht für unsere Zwecke aus). Das ist eine Menge, aber sie hat Löcher, wie man sich leicht klar machen kann, wenn man sich das ganze auf dem Zahlenstrahl vorstellt. Ebenso weisen die durch die Gleitkommadarstellung darstellbaren Werte als Teilmenge der reellen Zahlen "Löcher" auf, wenn man sie sich auf dem Zahlenstrahl vorstellt.
MfG,
Peter
//edit: ups, zu spät!
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
other
Hält's aus hier
Beiträge: 7
WindowsXP, Windows Vista
Delphi 5, Visual C# Express
|
Verfasst: Di 03.06.03 18:39
Hallo,
| Peter Lustig hat folgendes geschrieben: | Kaum geht man mal ein bisschen Einkaufen, schon muss man Massen an Postings beantworten!
|
Wieder Stapel an Pizzen besorgt?
| Zitat: |
(3) | other hat folgendes geschrieben: | | Klingt nach Comp. | Nach was?
|
Auszug OH: Der Typ Comp (für "computational") ist ein natives Format der Intel-CPU und stellt einen 64-Bit-Integer dar. Er ist dennoch als reeller Typ klassifiziert, weil sein Verhalten nicht dem eines ordinalen Typs entspricht (beispielsweise läßt sich ein Comp-Wert weder erhöhen noch erniedrigen). Comp ist nur aus Gründen der Abwärtskompatibilität vorhanden. Eine höhere Ausführungsgeschwindigkeit erhalten Sie mit dem Typ Int64.
| Zitat: |
(4) zu den Mengen mit Löchern: stell Dir mal den Zahlenstrahl vor und da darauf die rationalen Zahlen Q. Q ist dann definiert als Q := {k / n | k € Z, n € Z\{0}} wobei das Eurozeichen mal für das "Element-aus-Zeichen" herhalten musste und Z natürlich alle ganzen Zahlen sind. (ich glaube, die Def. ist nicht ganz korrekt, weil einiges doppelt vorkommt, aber sie reicht für unsere Zwecke aus).
|
Def. ist i.O.
| Zitat: |
Das ist eine Menge, aber sie hat Löcher, wie man sich leicht klar machen kann, wenn man sich das ganze auf dem Zahlenstrahl vorstellt.
|
Löcher? Warum?
Probleme sehe ich erst bei den irrationalen Zahlen.
Diese Löcher im Strahlenzahl sind alle Zahlen, die unendlich und nichtperiodisch sind. Selbst unendliche periodische Zahlen lassen sich auf dem Zahlenstrahl darstellen. Schau mal, ob du im Web etwas zu dem 1. Strahlensatz findest.
| Zitat: |
Ebenso weisen die durch die Gleitkommadarstellung darstellbaren Werte als Teilmenge der reellen Zahlen "Löcher" auf, wenn man sie sich auf dem Zahlenstrahl vorstellt.
|
Das hängt damit zusammen, dass der Computer nicht mit unendlich großen Zahlenbereichen umgehen kann. Man hat im Gleitkommatyp immer nur begrenze Bits vorhanden, die für die Darstellung genutzt werden können. Das sind andere Löcher, als die der irrationalen Zahlen.
MfG Other.
_________________ Ein Forum ist ein Platz unbezahlter Arbeit.
|
|
|