natürliche zahlen gesucht!!!

03.06.2005, 12:52

Kuschler

natürliche zahlen gesucht!!!

Hi

Kann mir jemand helfen eine gleichenung zu finden die mir von einer fließkomma zahl die nachkomma stellen weg hackt so das ich eine realle zahl habe. Es soll nicht gerundet werden. einfach nur das alles nach dem komme verschwindet.

Hilfe

03.06.2005, 14:51

Leopold

Auf diesen Beitrag antworten »

Du beschreibst den Vorgang ja schon - und damit ist die Funktion gegeben. Was suchst du nun genau? Willst du diese Funktion mit Hilfe anderer bekannter Funktionen ausdrücken? Wenn ja, welcher Funktionenvorrat steht zur Verfügung? Oder geht es um ein Programmierproblem?

Bitte lege genauer dar, was du willst. Die Aufgabenstellung ist so nicht verständlich.

03.06.2005, 15:05

Kuschler

Auf diesen Beitrag antworten »

programmierproblemm is schon richtig Big Laugh

Ich möchte eine mathe matische gleichung mit der ich von reellen zahlen in natürliche zahlen umwandle aber so das immer gegen 0 gerundet wird (sprich immer abgerundet wird).

Das problemm hat sich ergeben weil ich in einem programm ständig einen fehler bekomme der aber nichts mit falscher programmierung zu tun hat sondern mit dem vorat des processors, so das ich am ende falsche werte erhalte.

Meine frage leutet als beispeil wie mache ich aus einer 2.4332 eine 2 oder aus 34078956.903856 eine 34078956 ?

03.06.2005, 15:21

JochenX

Auf diesen Beitrag antworten »

einfach als integer casten?

03.06.2005, 15:25

Kuschler

Auf diesen Beitrag antworten »

wenns nur mal so einfach wäre, was es leider nicht ist. Ich habe schon im forum nach geschaut bei delphi, doch die ham erstmal das problemm mit dem carsten erklärt das dort beim rechnen nin fehler beim processor passiert und mir geraten mich mal hier her zu begeben und nach einer lösung mit einer oder mehreren gleichungen zu suchen. Ich hab leider keine gefunden und nun frag ich euch halt!

03.06.2005, 15:27

Tobias

Auf diesen Beitrag antworten »

Was ist mit der unteren Gaußklammer?

$\begin{eqnarray*} \lfloor x \rfloor \end{eqnarray*}$

03.06.2005, 15:29

Kuschler

Auf diesen Beitrag antworten »

was ist die gaußklammer? tut mir leid soviel ahnung von mathe hab ich auch nicht, nur soviel das ich mit bits und bytes arbeiten kann smile

03.06.2005, 15:29

JochenX

Auf diesen Beitrag antworten »

Zitat:

das problemm mit dem carsten

armer carsten :'-(

is das eigentlich nicht eher was fürs infoboard?

gaußklammer macht ja sinn, aber was soll das immer mit der mathematischen Gleichung?!

03.06.2005, 15:36

jovi

Auf diesen Beitrag antworten »

Versuch dein Problem doch bitte etwas präziser zu formulieren - das ist ja reinstes rumgerate.
Hat nun Delphi ein Problem mit den casten oder dein Prozessor und bei welchen Beispielen (casts) tritt das Problem auf ?

03.06.2005, 15:38

etzwane

Auf diesen Beitrag antworten »

in jeder Programmiersprache gibt es doch sowas wie k=integer(x), meistens int(x). Sogar der Funktionsplotter hier im Board versteht den Befehl. Man sollte jedoch den Funktionswert für negative Zahlen überprüfen.

03.06.2005, 16:22

Leopold

Auf diesen Beitrag antworten »

aus der Delphi-Hilfe

function Floor(const X: Extended): Integer; (Unit Math)

Beschreibung
Floor rundet die mit X angegebene Variable folgendermaßen ab:
Floor(-2.8) = -3
Floor(2.8) = 2
Floor(-1.0) = -1

function Ceil(const X: Extended):Integer; (Unit Math)

Beschreibung
Mit Ceil können Sie den kleinsten Integer-Wert ermitteln, der größer oder gleich X ist. Der absolute Wert von X muß kleiner als MaxInt sein. Einige Beispiele:

Ceil(-2.8) = -2
Ceil(2.8) = 3
Ceil(-1.0) = -1

function Round(X: Extended): Int64;

Beschreibung
Round rundet einen Wert des Typ Real auf einen Integer-Wert.
X ist ein Ausdruck des Typs Real. Zurückgegeben wird ein Int64-Wert mit dem auf die nächste ganze Zahl gerundeten Wert von X. Liegt X genau in der Mitte zwischen zwei ganzen Zahlen, wird immer die gerade Zahl zurückgeliefert. Dieses Vorgehen beim Runden wird auch als ”Banker’s Rounding” bezeichnet.
Liegt der gerundete Wert von X außerhalb des Int64-Wertebereichs, wird ein Laufzeitfehler ausgelöst, der mit einer EInvalidOp-Exception behandelt werden kann.

function Trunc(X: Extended): Int64;

Beschreibung
Trunc konvertiert eine Gleitkommazahl in einen Integer-Wert.
X ist ein Gleitkommaausdruck. Die Funktion gibt einen Int64-Wert mit dem gegen 0 gerundeten Wert von X zurück.
Liegt der Integer-Wert von X außerhalb des Wertebereichs einer Int64-Zahl, tritt ein Fehler auf, der mit einer EInvalidOp-Exception behandelt werden kann. Wird keine Fehlerbehandlung durchgeführt, tritt ein Laufzeitfehler auf.

function Int(X: Real): Real;

Beschreibung
Int gibt den ganzzahligen Anteil von X zurück, also X gegen 0 gerundet. X ist ein Ausdruck des Typs Real.

function Frac(X: Extended): Extended;

Beschreibung
Frac gibt den Nachkommaanteil der im Parameter X übergebenen reellen Zahl zurück.
X ist ein Ausdruck eines Real-Typs. Der Rückgabewert ist der Nachkommaanteil von X, d.h.Frac(X) = X - Int(X).

03.06.2005, 18:48

Auf diesen Beitrag antworten »

... und in der C-StdLib ist da ganz ähnlich, hier gleich mit Beispielen:

(int)(2.3) = 2
floor(2.3) = 2.0
ceil(2.3) = 3.0

(int)(-2.3) = -2
floor(-2.3) = -3.0
ceil(-2.3) = -2.0

04.06.2005, 10:20

Kuschler

Auf diesen Beitrag antworten »

Hey danke

das is doch schon mal ne hilfe mit ceil und floor. Ich muss dann nur noch schaun ob es geht. Negative zahlen werden nicht verwendet im programm.

Bei mir ist mit int() und trunc() ein fehler aufgetretten. Es ist richtig das beide mehr oder wehniger integerwerte livern. Doch ich hab den fehler raus gefunden in dem ich von 1 bis 10 rechnen lies, ich hab immer +0.1 dazu rechenen lassen bis 10 bis 8 klappt das ja, doch bei 9 heut es ihn dann föllig aus der bahn.

als beispeil:

var
x: double;
begin
x:=1;
repeat
x:=x+0.1;
memo1.lines.add(floattostr(x));
until x>10;
end;

Fürt das mal aus und beobachtet mal die ergebnisse, das ist nämlich der grund dafür das bei mir trunc und ähnliches nicht funtioniert. Hier mal hinweisender link dazu:

http://www.delphi-forum.de/viewtopic.php?t=42885&highlight=real

04.06.2005, 16:43

Leopold

Auf diesen Beitrag antworten »

Das Problem ist letztlich, daß die reellen Zahlen $\begin{eqnarray*} \mathbb{R} \end{eqnarray*}$ eine mathematische Fiktion sind, die in der wirklichen Welt keine Entsprechung besitzen. Eine reelle Zahl ist ein unendliches Objekt, z.B. in ihrer Darstellung als unendlicher Dual- oder Dezimalbruch. Ein Rechner, mag er auch Terabyte an Speicher besitzen, kann aber nur endliche Objekte darstellen. Mit dem Versuch, eine reelle Zahl durch den Rechner zu repräsentieren, ist also stets ein Informationsverlust verbunden: das Runden vergröbert und verfälscht. So kann es passieren, daß bei

$\begin{eqnarray*} 0{,}1+0{,}1+0{,}1+\ldots+0{,}1 \ \text{(hundertmal)} \end{eqnarray*}$

der Rechner nicht $\begin{eqnarray*} 10 \end{eqnarray*}$ herausbekommt, da der Dezimalbruch $\begin{eqnarray*} 0{,}1 \end{eqnarray*}$ als Dualbruch die periodische Darstellung

$\begin{eqnarray*} 0{,}1_{\text{dezimal}} = 0{,}0\overline{0011}_{\text{dual}} \end{eqnarray*}$

besitzt. Nun kann aber der Rechner mit diesem unendlichen Objekt nicht rechnen, also rundet er, z.B. (vereinfacht)

$\begin{eqnarray*} 0{,}0\overline{0011}_{\text{dual}} \to 0{,}00011001100110011001100110011001_{\text{dual}} \end{eqnarray*}$

Und statt mit der korrekten Darstellung rechnet er mit dem Objekt rechts. Und das 100mal ergibt nun einmal nicht exakt $\begin{eqnarray*} 10 \end{eqnarray*}$ .

Ich habe mir angewöhnt, wo immer es möglich ist, auf das Rechnen mit Fließkommazahlen zu verzichten. Und es geht öfter, als man zunächst annehmen mag ...

04.06.2005, 20:10

sqrt(2)

Auf diesen Beitrag antworten »

Deshalb sollte man beim Rechnen mit Fließkommazahlen immer beachten, wie viele signifikante Stellen sie haben, und entsprechend runden. Die durch standardisierten Datentypen IEEE single und IEEE double haben 24 bzw. 53 signifikante Dualstellen, d.h. sicher gerundet 7 bzw. 15 signifikante Dezimalstellen. Vor dem Ausgeben von Ergebnissen muss man eben auf die angegebene Anzahl an Stellen runden.

[edit]"Signifikante Stellen" sind nicht zu verwechseln mit "Nachkommastellen". Die Eigenschaft von Fließkommazahlen ist eben, nicht eine feste Anzahl von Vorkomma- und Nachkommastellen zu haben. Signifikante Stellen sind Vorkommastellen ohne führende Nullen plus Nachkommastellen ohne die folgenden Nullen; bei 123,4567 haben wir also 7 signifikante Stellen und damit ist das Maximum von IEEE single schon erreicht, obwohl wir nur 4 Nachkommastellen haben.[/edit]

04.06.2005, 23:53

Auf diesen Beitrag antworten »

Nicht zu vergessen die Auslöschungseffekte bei Addition und Subtraktion, die die gewohnte exakte Mathematik auf den Kopf zu stellen scheinen: So kann man am PC bereits schön beobachten, dass bei Verwendung von IEEE single (24 Bit Mantisse) die Reihe

$\begin{eqnarray*} \sum\limits_{n=1}^{\infty}\frac{1}{n} \end{eqnarray*}$

numerisch konvergiert, und das in sehr kurzer Zeit. Zumindest wenn die Partialsummen sukzessive durch Aufsummieren in "normaler" Reihenfolge gebildet werden:
s := 0 ;
s := s+1/1 ;
s := s+1/2 ;
s := s+1/3 ;
...
Ab $\begin{eqnarray*} n=2^{21}=2097152 \end{eqnarray*}$ ist Schluß - die numerische Partialsumme wächst nicht mehr und bleibt bei ca. 15.403683 stehen.

Neue Frage »

Antworten »

natürliche zahlen gesucht!!!

Verwandte Themen