JavaScript Wie wird eine Dezimalzahl mit zwei Nachkommastellen in einen Bruch umgewandelt?

[simpsonsfan]

@BeBur Dabei weiß doch jeder, dass ein Drittel = 0,3 ist. Während π=1 ist.
Die Anforderung (dafür) war ja, dass alle Werte mit einer Unsicherheit von ±1% als Bruch mit möglichst kleinem Nenner angenähert werden sollen. (Und gleichzeitig hatten alle Werte zwei Nachkommastellen, konnten also mit einer Stückelung auf 1/100 exakt wiedergegeben werden.)
Und wenn einem die Unsicherheiten bewusst sind und man sie akzeptiert (und die Fehlerfortpflanzung dann beispielweise beim Endergebnis ### -90% / +600% ergibt), dann kann man das schon so machen.

Dass das Vorhaben prinzipiell keine allzu gute Idee ist, sehe ich auch so. Aber interessehalber kann man das schon mal machen. Genauso, wie ich mir interessehalber die Implementierung von Fraction.limit_denominator() aus der Python-Standardbibliothek angeschaut habe. Da ist auch in der Doku ein nettes Anwendungsbeispiel, das zeigt, dass bspw. der numerisch berechnete Cosinus von 30° damit wieder schön auf 1/2 aufgelöst wird.

Edit: Und da ich grade schon schreibe, eine kleine Korrektur zu #29. In Zeile 13 muss das dividieren durch 100 weg, wie zwei Posts später richtig angemerkt.
Da aber eine andere Frage an @madmax2010 In Zeile 31 deines Codes schreibst du (oder deine KI)

CORRECTION: Checking the ratio (dividing) is unstable

Was soll denn am Dividieren unstable sein? Ich ziele dort ja bewusst auf einen prozentualen Fehler ab. Und gleichzeitig wurde zuvor sichergestellt, dass beide Werte (Divisor und Dividend) >0 sind. Ich sehe da gerade nichts Instabiles. Wie ist das gemeint?

 

[SaschaHa]

Ich verstehe hier nicht, was mit "behandeln" gemeint ist.

Im Sinne einer Fallunterscheidung für die Zahlen mit den beschriebenen Eigenschaften. Streng genommen bezieht sich das Wort also auf die "Fälle", nicht die zugrunde liegenden Dezimalzahlen selbst.

• Fall 1: round(a) ist gleich a
• Fall 2: round(a) ist ungleich a

Da die angezeigte Dezimalzahl ja auf 2 Nachkommastellen gerundet werden soll, kann diese folglich vom ursprünglichen Sollwert in der Zelle abweichen, wodurch eine unmittelbare Umwandlung in eine rationale Zahl folglich wenig Sinn ergibt, sofern man den Anspruch hat, einen genauen Bruch und keine Approximation anzugeben. Dafür mein Vorschlag mit dem Hinweisfenster, in das man genau diesen Fall auslagern kann.

Beispiel:

• a = 0,125 = 1/8
• round(a) = 0,13 = 13/100 != 1/8

Statt nun also entweder 13/100 für den gerundeten oder 1/8 für den korrekten ursprünglichen Wert mit anzugeben, ließe sich das eben in ein Hinweisfenster auslagern, in dem dann alle 4 Werte stehen:

	Dezimalzahl	Rationale Zahl
Sollwert	0,125	1/8
Gerundet	0,13	13/100

Das ist wie gesagt nur ein persönlicher Vorschlag, der sowohl das Hauptfenster clean hält, als auch per Klick zusätzliche Informationen liefert. Auch Sonderfälle wie mit periodischen Zahlen ließen sich dorthin auslagern und entsprechend behandeln, wie in meinem vorherigen Post beschrieben.

 

[Keylan]

Was ist den nun die eigentliche Anforderung?

So wie im Eingangspost beschrieben ist das ja lange gelöst. Und jetzt dreht sich die Diskussion wieder mehr darum was das neue Problem jetzt eigentlich sein soll, statt passende Lösungen bereitstellen zu können.

Das die Idee mit diesen +-1% für nahezu jedes Anwendungsscenario eine ganz schlechte Idee ist müssen wir doch nicht weiter ausführen oder?

 

[tollertyp]

@SaschaHa: Okay, du meinst für die Anzeige die Unterscheidung, wenn ich dich richtig verstanden habe?

 

[SaschaHa]

@tollertyp
Ja. Sofern ich den TE richtig verstanden habe, geht es bei der "Umwandlung" in eine rationale Zahl ja vor allem darum, dem Nutzer eben diese alternative Darstellung der ursprünglichen Zahl präsentieren zu können.

 

[tollertyp]

Was der TE denkt, was er braucht, und das was er tatsächlich braucht, sind nicht immer das gleiche...

 

[kali-hi]

Geht das mit einer Formel?

Sorry, ich bin mir immer nicht ganz sicher, wann in der echten Mathematik von Formel, Berechnung, Term, Algorithmus, Verfahren, Regel oder Satz gesprochen wird... In der Programmierung/Informatik spricht man eigentlich von Algorithmus, Methode, Funktion oder Prozedur. Ich denke, die Abgrenzungen untereinander sind mitunter auch fließend...

Was ist den nun die eigentliche Anforderung?

So wie im Eingangspost beschrieben ist das ja lange gelöst. Und jetzt dreht sich die Diskussion wieder mehr darum was das neue Problem jetzt eigentlich sein soll, statt passende Lösungen bereitstellen zu können.

Das die Idee mit diesen +-1% für nahezu jedes Anwendungsscenario eine ganz schlechte Idee ist müssen wir doch nicht weiter ausführen oder?

Die Anforderung (dafür) war ja, dass alle Werte mit einer Unsicherheit von ±1% als Bruch mit möglichst kleinem Nenner angenähert werden sollen. (Und gleichzeitig hatten alle Werte zwei Nachkommastellen, konnten also mit einer Stückelung auf 1/100 exakt wiedergegeben werden.)
Und wenn einem die Unsicherheiten bewusst sind und man sie akzeptiert (und die Fehlerfortpflanzung dann beispielweise beim Endergebnis ### -90% / +600% ergibt), dann kann man das schon so machen.

Also, es geht nur darum, dass ganz zum Schluss für die Matrix einmal die Funktion print(true); aufgerufen werden soll. Diese nimmt sich die letzte Spalte der Matrix (also nicht die Koeffizienten, sondern nur die Ergebnisse, welche als floating points vorliegen). Diese Ergebnisse sollen dann auf "schöne Brüche" "gerundet" werden und für den Benutzer ausgegeben werden. Das soll heißen, es geht nur um eine temporäre Darstellung der Endergebnisse. Deshalb kann meiner Ansicht nach eine solch hohe Abweichung auch nicht auftreten.

Wenn man so will, geht es also um die Darstellung von angenäherten, kleinen Brüchen...

Woher kommt bei dir das "100x100"?

Ich dachte, es ginge nur um alle Dezimalzahlen der Form xx.yy das sind genau 10.000 (0.00, 0.01, 0.02 usw.)

51.05 ist doch etwas anderes als 1.05. Oder?

 

[Keylan]

Ich dachte, es ginge nur um alle Dezimalzahlen der Form xx.yy

Die Anforderung kam von dir, aber deine Formulierung ging auf Dezimalzahlen mit zwei Nachkommastellen. Da gehört dann auch 100.000,05 dazu.

 

[tollertyp]

Ich dachte, es ginge nur um alle Dezimalzahlen der Form xx.yy das sind genau 10.000 (0.00, 0.01, 0.02 usw.)

51.05 ist doch etwas anderes als 1.05. Oder?

Ich hab jetzt aber echt nochmal im ganzen Thread versucht zu suchen, woher plötzlich xx.yy kommt... ich habs nicht gefunden...

51 = 51 + 1/20 = (51 * 20 + 1) / 20
1 = 1 + 1/20 = (1 * 20 + 1) / 20
Man kann aber natürlich auch alles redundant pflegen...

 

[foofoobar]

Dabei weiß doch jeder, dass ein Drittel = 0,3 ist. Während π=1 ist.

Völliger Quatsch: Pi hängt von lokalen Gesetzen ab: https://de.wikipedia.org/wiki/Indiana_Pi_Bill