Zahlen werden falsch gekürzt :?

[doubleflip]

Hallo liebe Community,
ich habe vor wenigen Tagen angefangen mit Java beizubringen und bin somit noch ein blutiger Noob. Vmtl. ist mein Anliegen dementsprechend ein blutiges Noobanliegen.
Derzeit versuche ich mich an einem Programm, welches mir zufällig generierte Lauf-Trainingspläne erstellt.
Jetzt habe ich folgendes Problem bei folgendem Code (Die Variable habe ich der Übersicht halber erstmal aufgeteilt und immer wieder neu zugewiesen):

public class Laufeinheit {

    
public Laufeinheit() {
    double route = (Traininggenerator.difficulty / 10);
    route = route - (((int)20 * Math.random() ) / 10);
    route = route - (route % 0.1);

Zur Erklärung
Ich lasse mir in der Mainmethode eine Instanz der Klasse Trainingsplan generieren. In der Klasse Trainingsplan lasse ich mir im Konstruktor eine Instanz Einlaufen der Klasse Laufeinheit generieren.
Wenn man den Schwierigkeitsgrad in der Konsole (difficulty) eingibt, sollte dementsprächend bei z.B. "50" eine zu Laufende Strecke von bsplw. 4.4 generiert werden.
in 80% der Fälle geschieht dies auch ! In 20 % der fälle wird eine Strecke wie bsplw. 3.4000000000000004 generiert. Jetzt frage ich mich weshalb dies geschieht .... Versuche gerade ununterbrochen den Code so anzupassen, dass lediglich eine einzige Kommastelle mitgeneriert wird.

Hoffe wer kann mir weiterhelfen. Vmtl. ist die Lösung extrem simpel und ich bin einfach zu unterbelichtet ... 😀


Liebe Grüße


Flip

 

[Xyz1]

Mach mal,
route = Math.round((route - (route % 0.1))*10)/10.0;
Es gibt noch bessere Wege das zu runden aber dazu Morgen mehr.

 

[doubleflip]

route = Math.round((route - (route % 0.1))*10)/10.0;
Es gibt noch bessere Wege das zu runden aber dazu Morgen mehr.

Okay, funktioniert.
Vielen dank 🙂 Wäre Super wenn du morgen erklären könntest was genau der Code davor gemacht hat und warum dieser Wert ausgegeben wurde .
Gute Nacht

 

[Xyz1]

Ganz lapidar gesagt, ist Deine Subtraktion (meist immer) ungenau.
Danke und Nacht

 

[LimDul]

Das Problem ist, Fließkommaarithmetik ist nicht genau, sondern immer mit Ungenauigkeiten versehen.

Genauso wie man im 10er System 1/3 nicht exakt darstellen kann, kann man im Binärsystem viele Zahlen nicht exakt darstellen.

Wenn du im 10er System 10/3*3 rechnest, kommt - wenn du mit einer endlichen Anzahl an Nachkommastellen arbeitest - nicht 10 raus, sondern 9,9999999999999999. Analog passiert es in deinem Beispiel im Binärsystem. Deswegen ist es bei Rechnungen mit float oder double immer anzuraten am Ende auf die benötigte Genauigkeit zu runden.

 

[doubleflip]

Genauso wie man im 10er System 1/3 nicht exakt darstellen kann, kann man im Binärsystem viele Zahlen nicht exakt darstellen.

Wenn du im 10er System 10/3*3 rechnest, kommt - wenn du mit einer endlichen Anzahl an Nachkommastellen arbeitest - nicht 10 raus, sondern 9,9999999999999999.

Habe noch ein bisschen rumexperimentiert und ja ich glaube ich muss es anders machen. Das Problem ist, dass die Gefahr, dass ein solcher Wert schon entstehen kann, wenn ich einen int-Wert mit 0.1 multipliziere. Wenn ich ihn mit 10 hingegen dividiere kriege ich da immer einen Wert X.0 raus, als ob automatisch gerundet wird.

Ich glaube ich setzte mich da in ein paar Wochen nochmal genauer ran und lass mir die Strecke einfach in Meter ausgeben, sodass ich nur int verwenden muss.

Danke für die ganze Hilfe.

 

[Xyz1]

Fließkommaarithmetik ist nicht genau, sondern immer mit Ungenauigkeiten versehen

Nein, diese Aussage ist falsch. Es gibt sehr wohl genauigkeitserhöhende Rechenoperationen.

@LimDul Ich finde es wichtig Anfängern keine falschen Aussagen beizubringen.

dass die Gefahr, dass ein solcher Wert schon entstehen kann, wenn ich einen int-Wert mit 0.1 multipliziere

Nein, diese Aussage ist auch falsch, basiert aber auf dem, was @LimDul im Vorfeld geschrieben hatte...

Das Ungenaue an Deinen Berechnungen ist Subtraktion eines Werts. Dennoch wird oft empfohlen, Geldbeträge nicht mit Fließkommazahlen zu berechnen.

 

[mrBrown]

Es gibt sehr wohl genauigkeitserhöhende Rechenoperationen.

Welche denn?

 

[Xyz1]

Welche denn?

Zum Beispiel * 0.1

 

[mrBrown]

Zum Beispiel * 0.1

Ah, also wenn ich eine sehr ungenaue Zahl mit 0,1 multipliziere, ist die danach genauer?

 

[Xyz1]

Nein, das nicht, aber sie wird zumindest nicht ungenau. Jedenfalls in den meisten Fällen.

 

[mrBrown]

Nein, das nicht, aber sie wird zumindest nicht ungenau. Jedenfalls in den meisten Fällen.

Ja gut, „genauigkeitserhöhend“ ist natürlich ein gebräuchliches Synonym für „wird in den meisten Fällen nicht ungenauer“, sorry, hätte ich wirklich dran denken müssen.

 

[Xyz1]

Gut, dann sagen "wir" genauigkeitserhaltend. Und Genauigkeitserhaltend ist nicht gleichzusetzen mit Ungenauigkeitshervorrufend.

 

[temi]

Sehr erheiternd 😀 😀 😀

Bringen wir Anfängern mal lieber keine falschen Aussagen bei und diskutieren über genauigkeitserhöhende Operationen, die zwar die Genauigkeit nicht erhöhen, aber wenigstens meistens nicht ungenauer sind. Ich schmeiß mich hinters Sofa!

(Edit: Nicht falsch verstehen, ich finde das echt total witzig!)

 

[LimDul]

Zum Beispiel * 0.1

Bullshit. 0.1 ist eine Zahl, die ist nicht mal genau darstellbar in Fließkommarithmetik.

Fließkommaarithmetik ist inhärent ungenau. Es gibt Rechenoperationen, darauf die tatsächlich exakt sind - aber das ist die Ausnahme und nicht die Regel.

 

[Xyz1]

Bullshit

Kannst Du Deinen natürlichen Umgangston abstellen? Wir sind nicht mehr im Kindergarten. Danke. Ich erspare mir zu schreiben dass das falsch ist.

 

[LimDul]

Siehe Bild.

 

[mrBrown]

Siehe Bild.

Du siehst nur nicht, dass der Wert viel genauer ist als nur 0,1!!11elf

 

[Xyz1]

Ja so hart das auch klingt, aber es gibt Darstellungsfehler und Rechenfehler. Beides ist nicht das gleiche.

 

[Xyz1]

sondern immer mit Ungenauigkeiten versehen

Also solche Aussagen einfach unterlassen, dann ist alles gut und andere müssen auch nicht so viel richtigstellen...

 

[thecain]

Eine klassische Tobias-Nrw/derWissende/Xyz1/... Diskussion

 

[Xyz1]

Also es gibt Ungenauigkeiten, aber bei extrem kleinen Zahlen, hier ging es aber um extrem große Zahlen:

		final double big_number = (long) 1e18;
		for (double d = 1; d != 1e29; d *= 10) {
			System.out.println(big_number / d * 0.1);
		}

1.0E17
1.0E16
1.0E15
1.0E14
1.0E13
1.0E12
1.0E11
1.0E10
1.0E9
1.0E8
1.0E7
1000000.0
100000.0
10000.0
1000.0
100.0
10.0
1.0
0.1
0.010000000000000002
0.001
1.0E-4
1.0E-5
1.0000000000000002E-6
1.0E-7
1.0000000000000002E-8
1.0000000000000003E-9
1.0000000000000002E-10
1.0000000000000001E-11

Allerdings wird d *= 10 bei extrem großen Zahlen für d auch schon "etwas" ungenau...

 

[httpdigest]

Also es gibt Ungenauigkeiten, aber bei extrem kleinen Zahlen, hier ging es aber um extrem große Zahlen

Es spielt keine Rolle, wie "groß" (Richtung +/-Inf) die Zahl ist. Das ist doch gerade das Geniale an Fließkommazahlen. Die Ungenauigkeit ist IMMER relativ zur Magnitude der Zahl. Siehe z.B. die Methode java.lang.Math.ulp(float). Diese gibt die absolute Ungenauigkeit des Argumentes an. In anderen Worten: In welchem Bereich hätte die Zahl ebenfalls liegen können, um als float immer noch als dieselbe float-Zahl repräsentiert worden zu sein.
Genau deswegen wird die Ungenauigkeit von IEEE 754 Operationen auch in "ulp" gemessen. Z.B. 0.5 ulp für die meisten Operationen.
Das, was du mit deinen Ausgaben als "Ungenauigkeit" bezeichnest, hat doch nur etwas mit der verwendeten Formatierung als String zu tun.

 

[m-oliver]

Also um richtige Beträge auf X Nachkommastellen zu erhalten habe ich z.B. bei Business-Software immer BigDecimal verwendet. Dies sollte eine erwartete Rundung wie im Starthread erwartet ergeben.

Siehe auch: http://www.javapractices.com/topic/TopicAction.do?Id=13

Zu beachten, wie im Link auch erklärt, sollte BigDecimal mit einem String und nicht mit einem double instantiiert werden um höchste Genauigkeit zu erhalten.

 

[Xyz1]

Also für seine ursprüngliche Formel

route = Math.round((route - (route % 0.1))*10)/10.0;

ist das eigentlich alles Wurscht.

 

[temi]

Kannst Du Deinen natürlichen Umgangston abstellen?

Finde ich schon wieder witzig, dass ausgerechnet du so etwas sagst...

 

[doubleflip]

public Laufeinheit() {
  
  
    int meterroute = (Traininggenerator.difficulty * 100);
    meterroute = meterroute + (int)(20 * Math.random()) * (2 * Traininggenerator.difficulty);
    meterroute = meterroute - (int)(20 * Math.random()) * (2 * Traininggenerator.difficulty);
    meterroute = meterroute - (meterroute % 100);
  
    System.out.println(" Laufen sie " + meterroute + " " + "m");
}

Danke für die ganzen Antworten 🙂
Ich lass mir die Strecke jetzt einfach in Metern berechnen, auch wenn ich dadurch ein bisschen aus der Problematik flüchte. Ich werde mich die Tage noch einmal befassen, aber wie ich das jetzt verstanden gibt es Möglichkeiten die Genauigkeit so zu erhöhen, dass die Häufigkeit von diesen, ich nenne sie mal Abweichungen (also z.b. 2.000000005), verringert wird. Naja ich muss ja nicht zwangsläufig für so etwas die Variable double nehmen.

Wenn ich den Code so wie oben ausführen lasse, generiert er mir die Laufstrecke so wie ich das will.

Der Code con Xyz1 hat bei dem von mir geposteten Code funktioniert. Das Problem ist, dass ich den Code noch einmal so verändern wollte, damit bei geringeren Schwierigkeitsgraden keine negativen Laufstrecken rauskommen bzw. diese bei höheren Schwierigkeitsgraden auch erhöhte Varianz aufweisen.



Vielen Dank, Liebe Grüße und Gute Nacht, Flip


PS: wollte keinen Streit provozieren.

 

[Xyz1]

Nu rechnest du alles in int, das ist natürlich auch möglich.