hab ein kleines Problem, ich lese neunstellige Zahlen aus einer Datei und möchte diese dann durch 100 teilen und in einer double variable abspeichern.
Jetzt werden aber bei der Teilung die Nachkommastellen auf .00 .25 .50 .75 gerundet. Das möchte ich nicht!!!
Ich hab folgendes versucht:

Alle Variablen sind double Variablen!
Casten der Berechnung mit

static_cast<double>

Multiplizieren mit 0.01!

Das Problem tritt immer auf!

Danke für Eure Hilfe

(PS: Was für Zahlen sind das eigentlich?)

Bei den Zahlen handelt es sich um Koordinaten, die in diesem Datenformat in der Einheit cm abgespeichert sind. Ich möchte allerdings, wie allgemein üblich die Einheit m!

Das mit der Interpretation gefällt mir nich so recht, da ich ein Großteil meines Programms ändern müßte, aber wenn es keine andere Möglichkeit gibt...
Danke

Und was spricht denn eigentlich dagegen, in Zentimeter zu rechnen? Die Umrechnung auf Meter brauchst du nur für die Ausgabe: "cout<<wert/100<<'.'<<wert%100;"

//Diese Zahl kommt eigentlich aus der Datei
int x = 354647828;
double x_neu = x/100;
//Wenn ich nun mit x_neu weiterrechne ist es gerundet auf 3546478.25

Es bringt wie gesagt nichts, wenn x auch double ist auch nicht wenn ich etwas in der Art mache:

x_neu = static_cast<double>(x/100);

@CStoll:
Alle anderen Datensätze in meinem Programm sind in der Einheit Meter, ich muß diese Daten ja zusammenbringen und Berechnungen durchführen und da muß ich irgendwann umrechnen und eigentlich hab ich keine Lust alle anderen Daten in Centimeter umzurechnen, ich brauch aber die Genauigkeit in den Nachkommastellen da es sich um Geodaten handelt...

a) Klappt es eventuell, wenn du "x/100.0" verrechnest?

b) Was macht es denn für einen Sinn, Strecken in der Größenordnung von 1000 km auf den Zentimeter genau zu bestimmen? Bist du sicher, daß du mit der Genauigkeit nicht etwas übertreibst?

a) Klappt es eventuell, wenn du "x/100.0" verrechnest?

Hab ich auch schon versucht, klappt net....

CStoll schrieb:

b) Was macht es denn für einen Sinn, Strecken in der Größenordnung von 1000 km auf den Zentimeter genau zu bestimmen? Bist du sicher, daß du mit der Genauigkeit nicht etwas übertreibst?

Mit diesen Koordinaten werden auch Strecken in der Größenordnung meter dargestellt und da macht es sehr wohl einen Sinn. Durch Messungen haben diese Koordinaten diese Genauigkeiten und die will ich mir nicht wegrunden lassen! Ich komm aus der Vermessungsbranche und normalerweise schauen wir auch noch auf die mm...
Auch wenn es kleinlich erscheint...

(Anmerkung: Ich wundere mich nicht über die benötigte Genauigkeit, sondern über die Größenordnung, in der du rechnen willst)

Was willst du denn da vermessen? Die Entfernung zwischen Hamburg und München auf den Zentimeter genau?

(Anmerkung: Ich wundere mich nicht über die benötigte Genauigkeit, sondern über die Größenordnung, in der du rechnen willst)

Okay, hier ein kleiner Crashkurs in Vermessungswesen.
Es gibt in Deutschland ein gängies Koordinatensystem, das Gauß - Krüger System, dies wird für ganz Duetschland benutzt.
Koordinaten im Gauß Krüger System haben alle 7 Stellen vor dem Komma. Ich stelle also 2 Punkte die einen Meter voneinander entfernt sind in GK Koordinaten , z.B. so da
P1(3500000.00/5400000.00) und P2(3500001.00/5400000.00)
Daher berechne ich mit diesen riesigen Koordinaten also nicht unbedingt riesige Strecken und daher benötige ich eine hohe Genauigkeit! Einigermaßen klar

(PS: Nur aus Neugierde - wo liegt eigentlich der Punkt (0/0) in etwa?)

Also, Unbekannter, versuchs mal mit long double statt double.

Guckst Du...
Nullpuntk: Schnitt 0° Meridian durch Greenwich mit Äquator..

Ja mein Problem besteht noch, was ist GMP??

@Unbekannter: GMP ist eine Bibliothek für den Umgang mit (wirklich) großen Zahlen - schau dich mal hier im Board um, das wurde schon ein paarmal genannt.

Also, Unbekannter, versuchs mal mit long double statt double.

Danke, aber leider nein....

@Michael: Das Problem dürfte nicht die Größe der Werte sein, sondern die Genauigkeit. Und da hat long double auch nicht zwingend eine höhere Auflösung (von Ganzzahltypen will ich hier gar nicht anfangen).

Dessen bin ich mir bewusst. Da ich aber davon ausgehe, dass das System des Unbekannten keine besonders abstrusen Datentypdarstellungen hat, reicht es vollkommen, auf einen 64-Bit-Datentyp zu gehen. 48 Bit würden auch schon reichen.

Also nix mit GMP.

Michael E. schrieb:

Also, Unbekannter, versuchs mal mit long double statt double.

Danke, aber leider nein....

Damit dieser Thread nicht im lustigen Rätselraten und dauernden GMP-Empfehlungen endet, nennst du uns bitte deinen Compiler und deine Architektur (wenns en PC ist, kannste das letzte weglassen).

Wäre die Idee bescheuert zu sagen, ich lese die Daten in einen String, Füge nach 7 Stellen einen Punkt in den string ein und schiebe das über einen stringstream in die double Variable! Könnte das klappen????

Nein.

Unbekannter schrieb:

Wäre die Idee bescheuert zu sagen, ich lese die Daten in einen String, Füge nach 7 Stellen einen Punkt in den string ein und schiebe das über einen stringstream in die double Variable! Könnte das klappen????

Nein.

Könnte das klappen -> Nein oder
Ist das bescheuert -> Nein

PC mit XP Visual Studio.net 2003

(von Ganzzahltypen will ich hier gar nicht anfangen).

Schade, gerade den interessanten Teil lässt du weg. Ganzzahltypen haben nämlich den ungemeinen Vorteil, dass sie keine Exponenten speichern müssen. Somit kann man sich ganz leicht was basteln:

typedef uint32 unsigned long;    // IIRC vom Standard garantiert

class MyOwnNumerType
{
public:
    MyOwnNumberType(uint32 value_) : value(value_);
    { }

    std::string Print()
    {
        std::stringstream ss;
        ss << value;
        std::string svalue;
        ss >> svalue;
        svalue.insert(svalue.length() - 2, ".");
        return svalue;
    }

private:
    uint32 value;
};

@Unbekannter: Die Bastelei mit dem Stringstream ist "bescheuert" und genauso exakt wie alle anderen bisherigen Versuche.

#include <iostream>
using namespace std;

int main()
{
    long double foo;
    cout << sizeof(foo);
}

Diesen Vorschlag hatte ich schon recht weit am Anfang gemacht - allerdings mit der Antwort "zu kompliziert und zu aufwändig".

@Unbekannter: Die Bastelei mit dem Stringstream ist "bescheuert" und genauso exakt wie alle anderen bisherigen Versuche.

Jau, das hab ich grad auch gemerkt...
Öhm, also ich seh schon ich muß mir da mal was anderes überlegen, Danke für Eure Hilfe....