Addition != Addition: Warum?

[Jonas2]

Hallo,

in C habe ich ein Phänomen, welches nach einer Erklärzung schreit. Wer hilft mir mal auf die Sprünge?

Jonas

[1unitedpower]

in C habe ich ein Phänomen, welches nach einer Erklärzung schreit. Wer hilft mir mal auf die Sprünge?

Floating-Point-Addition ist nicht assoziativ, d.h. (a + b) + c ist im Allgemeinen nicht das gleiche wie a + (b + c). Deine beiden Rechenwege sehen zunächst danach aus, als würden die Operationen in der selben Reihenfolge stattfinden, es kann aber sein, dass der C-Compiler die Varianten verschieden optimiert. Kannst du das Verhalten auch beobachten, wenn du ohne Optimierungen kompilierst?

[Jonas2]

Floating-Point-Addition ist nicht assoziativ, d.h. a + b ist im Allgemeinen nicht das gleiche wie b + a. Deine beiden Rechenwege sehen zunächst danach aus, als würden die Operationen in der selben Reihenfolge stattfinden, es kann aber sein, dass der C-Compiler die Varianten verschieden optimiert. Kannst du das Verhalten auch beobachten, wenn du ohne Optimierungen kompilierst?

Hi,

ich glaube, dass Du "auf dem richtigen Weg" (der mir unbekannt ist) bist. Leider habe ich gerade nur den Compiler zur Verfügung, den Ideone bietet.

Kannst Du mir ggf. trotzdem etwas über "die Optimierungen" sagen, die ein C-Compiler hier eigenständig vornimmt oder es eben auch nicht tut?

Jonas

[Matthias Apsel]

Hallo 1unitedpower,

Floating-Point-Addition ist nicht assoziativ, d.h. a + b ist im Allgemeinen nicht das gleiche wie b + a.

Du beschreibst Kommutativität.

Assoziativität wäre (a + b) + c = a + (b + c).

Bis demnächst
Matthias

[1unitedpower]

Du beschreibst Kommutativität.

Jep, sorry.

[Jonas2]

Du beschreibst Kommutativität.

Jep, sorry.

ja, irgendwie klingelts: kommutativgesetz..

Nur in diesem Zusammenhang kenn ichs nicht. Jonas

[1unitedpower]

Nur in diesem Zusammenhang kenn ichs nicht.

Dieser Wikipedia-Artikel hilft vielleicht: https://de.wikipedia.org/wiki/Gleitkommazahl#Ung.C3.BCltigkeit_der_Assoziativ-_und_Distributivgesetze

[Tagwächter]

Hallo,

in C habe ich ein Phänomen, welches nach einer Erklärzung schreit. Wer hilft mir mal auf die Sprünge?

Jonas

Ich habe das

#include <stdio.h>

void summe_float() {
    float x1 = 10000.0, x2 = -1.0e-3 / 9.0,x3 = 25.0e2, x4 = 1.0e-3 / 7.0, x5 = -12.5e3;
    float y = x1;
    y+=x2;
    y+= x3;
    y+= x4;
    y+= x5;

    float z = x1+x2+x3+x4+x5;

printf("Fall 1: (Addition schrittweise):%.21f \n",y);
printf("Fall 2: (Addition direkt):%.21f \n",z);
return 0;
}

int main() {
summe_float();
    return 0;
}

mal kopiert, compiliert und ausgeführt:

/tmp$ gcc -o test.bin test.c
test.c: In function ‘summe_float’:
test.c:15:1: warning: ‘return’ with a value, in function returning void [enabled by default]
 return 0;
 ^
/tmp$ ./test.bin 
Fall 1: (Addition schrittweise):0.000000000000000000000 
Fall 2: (Addition direkt):0.000000000000000000000 

[Tagwächter]

void summe_float() {
    float x1=10000.0;
    float x2=-1.0e-3/9;
    float x3=25.0e2;
    float x4=1.0e-3/7;
    float x5=-12.5e3;
    float y=x1;
    printf("Test A1: (Addition schrittweise):%.21f \n",y);
    y=y+x2;
    printf("Test A2: (Addition schrittweise):%.21f \n",y);
    y=y+x3;
    printf("Test A3: (Addition schrittweise):%.21f \n",y);
    y=y+x4;
    printf("Test A4: (Addition schrittweise):%.21f \n",y);
    y=y+x5;
    printf("Test A5: (Addition schrittweise):%.21f \n",y);

    float z;
    z=x1+x2+x3+x4+x5;
    printf("Test B: (Addition direkt):%.21f \n",z);
return;
}

Denksport:

Test A1: (Addition schrittweise):10000.000000000000000000000 
Test A2: (Addition schrittweise):10000.000000000000000000000 
Test A3: (Addition schrittweise):12500.000000000000000000000 
Test A4: (Addition schrittweise):12500.000000000000000000000 
Zahl X5: -12500.000000000000000000000 
Test A5: (Addition schrittweise):0.000000000000000000000 
Test B: (Addition direkt):0.000000000000000000000 

Netter Versuch.

[Jonas2]

Denksport:

Test A1: (Addition schrittweise):10000.000000000000000000000 
Test A2: (Addition schrittweise):10000.000000000000000000000 
Test A3: (Addition schrittweise):12500.000000000000000000000 
Test A4: (Addition schrittweise):12500.000000000000000000000 
Zahl X5: -12500.000000000000000000000 
Test A5: (Addition schrittweise):0.000000000000000000000 
Test B: (Addition direkt):0.000000000000000000000 

Netter Versuch.

Schön wärs :-(

Ich denke, 1unitedpower liegt nahe an der Lösung. Es könnte am Compiler und an dessen Optimierungen liegen. Aber damit kenne ich mich eben nicht aus.

Daher bleibt die Frage bestehen: Warum (genau)?

Jonas

[Tagwächter]

Es könnte am Compiler und an dessen Optimierungen liegen. Aber damit kenne ich mich eben nicht aus.

Dann gibt man erst mal an, womit und ggf. mit welchen Optionen man compiliert hat.

[Tagwächter]

Ich habe selbst was zu testen:

https://home.fastix.org/Tests/PHP:Feiertage/test-feiertage-form.php

(Projekt)

[Jonas2]

Ich habe selbst was zu testen:

https://home.fastix.org/Tests/PHP:Feiertage/test-feiertage-form.php

(Projekt)

Oops. Hast Du die Rechte, diesen Post als eigenen Thread wieder aus meiner Frage zu entfernen? Ich befürchte nämlich, dass meine Ursprungsfrage hierin verloren geht :-(

Oder hat Deine Frage irgendwie direkt etwas mit meiner Frage zu tun und ich merke es gerade nicht? Glaubst Du etwa, dass ich andere etwas für mich testen lassen möchte? ich verstehe das gerade nicht.

Jonas

[Google weiß alles]

Ich habe selbst was zu testen:

https://home.fastix.org/Tests/PHP:Feiertage/test-feiertage-form.php

(Projekt)

Oops. Hast Du die Rechte, diesen Post als eigenen Thread wieder aus meiner Frage zu entfernen?

Nein. Außerdem friert sich mein Prozessor den Popo ab. Hier der Grund.

[1unitedpower]

Ich mach hier zu, das führt sonst zu unnötiger Fragmentierung dieses und deiner Threads.

[Google weiß alles]

in C habe ich ein Phänomen, welches nach einer Erklärzung schreit. Wer hilft mir mal auf die Sprünge?

Ich erkärs Dir ...

Test A5: (Addition schrittweise):0.000000000000000000000 
Test B: (Addition direkt):0.000031746028980705887 

Das sieht aus wie ein Rundungsfehler. Die Zahlen werden ja binär mit endlichem Platz gespeichert und können also nicht beliebig genau sein. Du rechnest einerseits mit großen Zahlen und andererseits mit sehr kleinen Zahlen, wodurch die Genauigkeit, die float kann, auch vollständig ausnutzt.

Offenbar rundet Dein Kompiler bzw. dessen Kompilat bei jeder Zuweisung an eine Variable - was er/es bei der Kettenoperation gerade nicht macht und hat am Ende eine Zahl deren Abweichung zum Runden zu groß ist.

Im Ergebnis hast Du dann die Abweichung (in Test B) vom mathematisch richtigem Ergebnis (nach A5).

Warum ich mich verarscht gefühlt habe: Könnte eine Testfrage nach Kapitel 4 ("Datentypen") in "C-Grundlagen" sein.

Google weiß alles a.k.a. Tagwächter

[Jonas2]

Warum ich mich verarscht gefühlt habe: Könnte eine Testfrage nach Kapitel 4 ("Datentypen") in "C-Grundlagen" sein.

Ich denke, dass das mit der Testfrage stimmt. Aber nicht von mir und (so denke ich) auch nicht vom Prof. Aber auf meinem Weg zur Aufgabenbewältigung stehe ich genau vor diesem Problem (wie Ochs vom ...) Ich vesrtehe die Lösung immer nich nicht so ganz (was an der späten Uhrzeit liegen mag). Jedenfalls wolt ich Dich nicht veräppeln, schau mir die Lösung morgen früh nochmal an und frag bei Bedarf nach, ok?

Jonas

[Google weiß alles]

Ich vesrtehe die Lösung immer nich nicht so ganz

Die Lösung ist einfach: Da Compiler offenbar bei Kettenoperationen unterschiedliche Ergebnisse erzeugen ist die Strategie eben diese Kettenoperationen zu vermeiden - und zwar immer wenn die Stellenzahl/maximale Genauigkeit von float ausgelutscht werden könnte.

Die andere Lösung wäre eine Bibliothek zum Berechnen mit beliebigen Genauigkeiten (arbitrary precision) zu benutzen. bc könnte hierfür ein Beispiel sein. Und da es OpenSource ist kann man auch reinschauen.

Das ist aber teuer - Programme die so rechnen werden langsam. Also nur im Bedarfsfall.

[Rolf b]

Och Leute - seid ihr alle durch JavaScript und PHP soweit vom Blech abgehoben, dass ihr die Grundlagen nicht mehr kennt?

Einfache Genauigkeit
Fließkomma in C

Mit Kommutativität / Assoziativität hat das wenig zu tun. Sicher, in C ist die Reihenfolge der Operandenauswertung undefiniert, aber die Reihenfolge, in der die OPERATOREN angewendet werden, ist durch die Assoziativität bestimmt und deswegen erfolgt die Addition in Zeile 21 von links nach rechts.

Das Problem ist ein anderes: Die Genauigkeit von float ist winzig, es sind 23 Bit und damit ist $$2^{24}-1$$ der größte darstellbare Mantissewert. Also ca 16 Millionen, demzufolge 7-8 signifikante Stellen. Die Addition

10000
    0,000111
============
10000,000111

braucht 9 signifikante Ziffern, damit der kleine Summand nicht untergeht. Deswegen sind die Summanden x2 und x4 nach der Zuweisung an die Akkumulatorvariable float y verschwunden.

Wenn man y als double deklariert, ist das Problem weg. Vermutlich aus dem gleichen Grund, aus dem das bei dem langen Term anders ist; und ich würde es schon fast als Compiler-Bug ansehen. Es sei denn, K&R haben dem Compiler hier wieder mal die Freiheit der Interpretation gelassen, und eine Auswertung von float-Expressions mit double-Genauigkeit ist legitim. Fließkommaarithmerik macht ein Prozessor von heute jedenfalls mit der FPU und die arbeiten heute alle mit 64 oder 80 Bit, also double oder long double. Doppelte Genauigkeit hat 53 signifikante Bits oder 16 signifikante Dezimalstellen, und deswegen bleiben die Summanden dann erhalten.

Durch die interne genauere Rechnung haben sich am Ende die großen Werte gegenseitig ausgelöscht und man hat ein Ergebnis nahe 0. DAS kann dann wieder als float gespeichert werden.

In einem Uralt-C-Compiler, der noch Code für CPUs ohne FPU erzeugen kann, könnte man einmal einstellen, dass er eine 32-bit Float-Emulation nutzen soll (Fastmath oder sowas). Und dann dürfte auch die einzeilige Rechnung die kleinen Werte verlieren.

Rolf

[Rolf b]

Nachtrag 1: Ich hätte erwähnen sollen dass float und double compilerspezifische Angaben sind und nicht unbedingt 32-bit und 64-bit IEEE754 sein müssen. Aber die meisten Prozessoren von heute sind so.

Nachtrag 2: Habe jetzt in einem Online-Antiquariat eine 2. Auflage von K&R gefunden, da schreiben sie (Seite 198), dass die erste Auflage gefordert hat, dass float-Expressions in double ausgewertet werden und dass die zweite Auflage es erlaubt, float-Rechnungen in float durchzuführen. Was dem typischen C-Problem "Write Once, Test Everywhere" einen weiteren Schuss verpasst. Multiplattform-Programme in C bestehen aus mehr #if als Code, und pro Plattform wird oft genug nur die Hälfte des vorhandenen Source genutzt, der Rest ist eine Sonderimplementierung für andere Plattformen.

Nachtrag 3: Es wurde oben irgendwo gesagt, das Ergebnis A5 sei das mathematisch richtige. Seh ich anders, ich halte B für richtig - äh - näher an der Wahrheit. Fließkommazahlen sind selten ganz richtig (und sobald Nachkommastellen ins Spiel kommen, die sich nicht als Bruch mit einer Zweierpotenz im Nenner darstellen lassen, ist's auf jeden Fall aus).

Rolf

[Der-Dennis]

Hallo Rolf,

Nachtrag 3: Es wurde oben irgendwo gesagt, das Ergebnis A5 sei das mathematisch richtige. Seh ich anders, ich halte B für richtig - äh - näher an der Wahrheit. Fließkommazahlen sind selten ganz richtig (und sobald Nachkommastellen ins Spiel kommen, die sich nicht als Bruch mit einer Zweierpotenz im Nenner darstellen lassen, ist's auf jeden Fall aus).

ich hätte wohl zuerst den ganzen Thread lesen sollen…. Da warst Du deutlich früher dran als ich.

Gruß
Dennis

[Tagwächter]

Och Leute - seid ihr alle durch JavaScript und PHP soweit vom Blech abgehoben, dass ihr die Grundlagen nicht mehr kennt?

Also ich bin ja hoch glücklich, dass Du jetzt kommst und uns lang und breit nochmal erklärst, was ich schon kurz ausführte und 1united verlinkt hat.

[1unitedpower]

Och Leute - seid ihr alle durch JavaScript und PHP soweit vom Blech abgehoben, dass ihr die Grundlagen nicht mehr kennt?

So grundlegend ist das nicht, du liegst auch teilweise daneben. Im übrigen ist zumindest JS Arithmetik IEEE konform.

Sicher, in C ist die Reihenfolge der Operandenauswertung undefiniert

Das stimmt nicht. C verwendet eine left-most, inner-most Auswertungsstrategie für arithmetische Operatoren.

aber die Reihenfolge, in der die OPERATOREN angewendet werden, ist durch die Assoziativität bestimmt und deswegen erfolgt die Addition in Zeile 21 von links nach rechts.

Das stimmt nun wieder, aber das bedeutet nicht, dass die Addition auch dem Assoziativitätsgesetz folgt. Wir benutzen hier „Assoziativität“ für zwei unterschiedliche Sachverhalte, das sollten wir nicht durcheinander werfen.

Deswegen sind die Summanden x2 und x4 nach der Zuweisung an die Akkumulatorvariable float y verschwunden.

Das stimmt ebenfalls, das ist der Auslöschungseffekt. Es erklärt aber nicht, wieso der Fehler in der einen Berechnung auftritt und in der anderen nicht. Jedenfalls nicht, wenn man davon ausgeht, dass das Ergebnis einer Floating-Point-Addition wieder eine Floating-Point-Zahl ist.

Meine Vermutung war deshalb, dass mit einer Optimierungsstufe kompiliert wurde, die es dem Compiler erlaubt die Reihenfolge der Additions-Anwendungen zu variieren. Dann könnte aus a + b + c nämlich c + b + a geworden sein. Dann könnte in der einen Berechnung Auslöschung auftreten und in der anderen nicht. Deshalb kam ich auf die Nicht-Assoziativität.

Wirft man meine Annahme über Board, könnte man den Effekt auch damit erklären, dass C intern mit höherer Präzision rechnet. Darauf wolltest du vermutlich hinaus. Im Moment erscheint mir beides gleich wahrscheinlich.

[Rolf b]

Sicher, in C ist die Reihenfolge der Operandenauswertung undefiniert Das stimmt nicht. C verwendet eine left-most, inner-most Auswertungsstrategie für arithmetische Operatoren.

Wir reden hier von 3 verschiedenen Dingen. Du sprichst von left-most, inner-most, was sich auf die Auswertung von Funktionsargumenten bezieht, aber nicht auf die Auswertung von Ausdrücken als solches. Dazu kommt, dass deiner Behauptung Aussage vom C99 Standard widersprochen wird: Annex J sagt, dass die Reihenfolge der Auswertung von Funktionsargumenten undefiniert ist. Für C11 habe ich kein offizielles Standarddokument gefunden.

Zum zweiten ist da die Reihenfolge, wie die Werte von Operanden für Operatoren bestimmt werden. Die ist per Definitionem undefiniert, und das begründen K&R damit, dass sie dem Programmierer abgewöhnen wollen, sich auf Compilerspezifika zu verlassen. In C99 steht diese Undefiniertheit - wieder Annex J - auch noch drin. D.h. wenn die Operanden A,B,C in einem Term x=A+B+C Funktionsaufrufe oder Teilausdrücke sind, dann ist die Reihenfolge der Funktionsaufrufe bzw. die Werteermittlung undefiniert.

Drittens haben wir die Reihenfolge, in der Operatoren auf die gefundenen Werte angewendet werden. Und die ist NICHT undefiniert, die ist über die Assoziativität klar festgelegt. D.h. wenn ich A+B+C schreibe, wird erst A+B gerechnet und dazu C addiert. Im C99 Standard steht, dass der Compiler das bei Integer-Operationen umordnen darf, wenn die Hardware es zulässt (sprich: keine Overflow-Interrupts entstehen und Überläufe sich gegenseitig neutralisieren). Aber eben nur bei Integer, nicht bei Float. Gerade weil wegen der begrenzten Genauigkeit von float/double Variablen das Kommutativ-, Assozativ- und Distributivgesetz der Mathematik nicht anwendbar sind, darf der Compiler nicht umordnen, sondern muss sich strikt an die definierte Anordnung halten.

Das stimmt nun wieder, aber das bedeutet nicht, dass die Addition auch dem Assoziativitätsgesetz folgt. Wir benutzen hier „Assoziativität“ für zwei unterschiedliche Sachverhalte, das sollten wir nicht durcheinander werfen.

Genau :)

Deswegen sind die Summanden x2 und x4 nach der Zuweisung an die Akkumulatorvariable float y verschwunden.

Das stimmt ebenfalls, das ist der Auslöschungseffekt. Es erklärt aber nicht, wieso der Fehler in der einen Berechnung auftritt und in der anderen nicht. Jedenfalls nicht, wenn man davon ausgeht, dass das Ergebnis einer Floating-Point-Addition wieder eine Floating-Point-Zahl ist.

Nein, davon wird es nicht erklärt. Das kommt später.

Meine Vermutung war deshalb, dass mit einer Optimierungsstufe kompiliert wurde, die es dem Compiler erlaubt die Reihenfolge der Additions-Anwendungen zu variieren. Dann könnte aus a + b + c nämlich c + b + a geworden sein. Dann könnte in der einen Berechnung Auslöschung auftreten und in der anderen nicht. Deshalb kam ich auf die Nicht-Assoziativität.

Du meinst (a+b)+c und a+(b+c), andernfalls wäre es Kommutativität ;-). Das Thema "Umordnen von Float-Ausdrücken" hatte ich oben schon erwähnt, und ich habe nichts vermutet, sondern im Standard nachgelesen.

Wirft man meine Annahme über Board, könnte man den Effekt auch damit erklären, dass C intern mit höherer Präzision rechnet. Darauf wolltest du vermutlich hinaus. Im Moment erscheint mir beides gleich wahrscheinlich.

Wir brauchen keine Wahrscheinlichkeitsrechnung, es ist im Standard definiert (5.1.2.3 Nr. 11; 5.2.4.2.1, Nr. 8)): Float-Berechnungen werden mit höchstmöglicher Präzision ausgeführt und erst beim Zuweisen wird gerundet. Der Compiler DARF mit kleinerer Genauigkeit rechnen, wenn er für sich beweisen kann, dass das zum gleichen Ergebnis führt wie die genauere Rechnung.

Rolf

[1unitedpower]

Wir reden hier von 3 verschiedenen Dingen. Du sprichst von left-most, inner-most, was sich auf die Auswertung von Funktionsargumenten bezieht, aber nicht auf die Auswertung von Ausdrücken als solches.

Ich hab schon die Evaluierungsstrategie für Operanden gemeint, aber da hab ich mich wohl trotzdem geirrt und dir Unrecht getan.

[Rolf b]

:-) Hand reich...

[Der-Dennis]

Hallo Google,

Test A5: (Addition schrittweise):0.000000000000000000000 
Test B: (Addition direkt):0.000031746028980705887 

[Erklärung Rundungsfehler]

das sollte die richtige Erklärung sein, aber …

Im Ergebnis hast Du dann die Abweichung (in Test B) vom mathematisch richtigem Ergebnis (nach A5).

… ich denke die Schlussfolgerung ist falsch oder Du hast Dich verschrieben. Nur weil das „krumme“ Ergebnis wie so ein üblicher Rundungsfehler aussieht, muss es nicht das falsche Ergebnis sein. Kann man bei so einer einfachen Aufgabe auch noch schnell von Hand ausrechnen:

$$ 10000.0+-1.0e-3 / 9.0+25.0e2+1.0e-3 / 7.0+-12.5e3 $$
$$ = 10000+2500-12500+(\frac{1}{7}-\frac{1}{9}) \times 10^{-3} $$
$$ =\frac{2}{63}\times10^{-3}=0.0000\overline{317460} $$

(In der Hoffnung, mich hier am Handy nicht verschrieben zu haben; das 2/63 eine Periode ergibt sagt mein Taschenrechner)

Test B, die Verkettung, wäre damit näher am richtigen Ergebnis dran, ist aber dennoch Fehlerbehaftet. Irgendwie begründest Du das in der Erklärung auch schon selbst. Aber irgendwo scheint da was durcheinander geraten zu sein.

Gruß
Dennis

[Matthias Apsel]

Hallo Der-Dennis,

dass 2/63 eine Periode ergibt, sagt mein Taschenrechner

Wenn man Dezimalzahlen voraussetzt, gilt:

• Besitzt der Nenner (> 1) eines vollständig gekürzten Bruches nur die Primfaktoren 2 und 5, so ist seine Dezimalbruchdarstellung endlich.
• Besitzt er nur andere Primfaktoren als 2 und 5, so ist seine Dezimalbruchdarstellung sofortperiodisch.
• Besitzt er beide „Sorten“ von Primfaktoren, so ist seine Dezimalbruchdarstellung spätperiodisch. Die Länge der Vorperiode ist gegeben durch das Maximum der Anzahl der Primfaktoren 2 und 5.

Bis demnächst
Matthias

[Google weiß alles]

Dann wären noch PI und Euler... Ob das Ergebnis der Divison durch diese Zahlen periodisch ist oder nicht kann man nicht zeigen weil die Periode unendlich lang wäre.

[Der Martin]

Hallo,

Dann wären noch PI und Euler...

... die aber streng mathematisch betrachtet hier nicht hingehören. Denn die gehören zu den reellen, nicht aber zu den rationalen Zahlen. Sie sind also nicht als Quotient zweier Ganzzahlen darstellbar, sondern immer nur näherungsweise (wie z.B. der gern verwendete Ersatzwert 22/7 für pi).

Ob das Ergebnis der Divison durch diese Zahlen periodisch ist oder nicht kann man nicht zeigen weil die Periode unendlich lang wäre.

Man kann aber umgekehrt argumentieren: Wäre die Dezimaldarstellung von pi oder e periodisch, dann gäbe es auch zwei Ganzzahlen (auch wenn sie sehr groß sein mögen), mit denen man pi oder e als Bruch exakt darstellen könnte.

So long,
 Martin

[Google weiß alles]

Man kann aber umgekehrt argumentieren: Wäre die Dezimaldarstellung von pi oder e periodisch, dann gäbe es auch zwei Ganzzahlen (auch wenn sie sehr groß sein mögen), mit denen man pi oder e als Bruch exakt darstellen könnte.

So kannten römische Techniker die Näherung 22/7 für die "Kreiszahl" ... und seit dem wurde lang daran herumgerechnet.

[Gunnar Bittersmann]

@@Google weiß alles

Dann wären noch PI und Euler... Ob das Ergebnis der Divison durch diese Zahlen periodisch ist oder nicht kann man nicht zeigen weil die Periode unendlich lang wäre.

?? Es gibt keine unendlich lange Periode.

Es gibt periodische Dezimalbrüche – das sind die rationalen Zahlen. Und es gibt nichtperiodische Dezimalbrüche – das sind die irrationalen Zahlen.

LLAP 🖖

[Der-Dennis]

Hallo Matthias,

dass 2/63 eine Periode ergibt, sagt mein Taschenrechner

da habe ich mich verschrieben. Es sollte „diese Periode“ heißen, nicht „eine Periode“. Ich wollte damit ausdrücken, dass ich das nicht mal eben im Kopf gerechnet habe (weil ich vorher geschrieben hab, wie einfach das zu rechnen ist; 2/63 in Dezimaldarstellung im Kopf auszurechnen macht mir aber keinen Spaß).

Wenn man Dezimalzahlen voraussetzt, gilt:

• Besitzt der Nenner (> 1) eines vollständig gekürzten Bruches nur die Primfaktoren 2 und 5, so ist seine Dezimalbruchdarstellung endlich.
• Besitzt er nur andere Primfaktoren als 2 und 5, so ist seine Dezimalbruchdarstellung sofortperiodisch.
• Besitzt er beide „Sorten“ von Primfaktoren, so ist seine Dezimalbruchdarstellung spätperiodisch. Die Länge der Vorperiode ist gegeben durch das Maximum der Anzahl der Primfaktoren 2 und 5.

Da erinnere ich mich noch dunkel aus meiner Schulzeit dran. Aber gut, dass Du es hier schreibst. Jetzt habe ich das zumindest in der nächsten Zeit wieder auf dem Schirm :-)

Aber: Ich glaube auch nicht, dass ich sonderlich gut darin wäre, 31500 in seine Primfaktoren zu zerlegen.

Obwohl, wo ich gerade so darüber nachdenke: So schwer kann das eigentlich gar nicht sein, wenn man sich den Ausdruck $$ \frac{2}{63}\times10^{-3} $$ ansieht. $$ \frac{2}{63} $$ ist bereits vollständig gekürzt, bei $$ 63 = 9\times7 $$ sieht man die Primfaktoren 3, 3, 7 schon sehr gut. Und dann „Komma nach rechts verschieben“. Ok, das ist etwas gemogelt.
Hmm, kurz weiter überlegen. Aha! Da die Zehnerpotenzen immer 2 und 5 als Primfaktoren haben und im Zähler eine 2 steht: $$ \frac{\not{2}}{(3\times3\times7)\times(\not{2}\times5\times2\times5\times2\times5)} $$. Die Primfaktoren müssten dann 2, 2, 3, 3, 5, 5, 5, 7 sein, oder?

Gruß
Dennis

[Gunnar Bittersmann]

@@Der-Dennis

das 2/63 eine Periode ergibt sagt mein Taschenrechner

Nein. Dein Taschenrechner zeigt sowas wie 0,03174603174603 an.

Du kannst vermuten, dass es danach periodisch weitergeht, aber der Taschenrechner sagt das nicht.

LLAP 🖖

[Der-Dennis]

Hallo Gunnar,

das 2/63 eine Periode ergibt sagt mein Taschenrechner

da hab ich mich leider verschrieben.

Nein. Dein Taschenrechner zeigt sowas wie 0,03174603174603 an.

Nein. (der von mir auf dem Handy benutzte Taschenrechner)

Du kannst vermuten, dass es danach periodisch weitergeht, aber der Taschenrechner sagt das nicht.

Doch. (mein sozusagen „analoger“ Taschenrechner; siehe Seite 12)

Wenn der Taschenrechner da einen Strich über die Zahlen drüber malt und das nicht wie ein Displayfehler aussieht, behaupte ich weiterhin „sagt der Taschenrechner“ und nicht „ich vermute“.
Taschenrechner sind heutzutage nicht mehr so groß wie ein Wohnzimmer und können häufig mehr als nur die Grundrechenarten und auf einfachste Art und Weise 10 Ziffern anzeigen.

Gruß
Dennis

[Tabellenkalk]

Hallo,

Taschenrechner sind heutzutage nicht mehr so groß wie ein Wohnzimmer

Taschenrechner waren noch nie so groß wie ein Wohnzimmer!

Gruß
Kalk

[Der-Dennis]

Hallo Kalk,

Taschenrechner sind heutzutage nicht mehr so groß wie ein Wohnzimmer

Taschenrechner waren noch nie so groß wie ein Wohnzimmer!

Taschenrechner sehen auch gar nicht aus wie eine Tasche!! ;-)

Gruß
Dennis

[Tabellenkalk]

Hallo,

Taschenrechner sehen auch gar nicht aus wie eine Tasche!! ;-)

Ja, Taschenmesser und Taschentücher auch nicht. Und nun?

Gruß
Kalk

[Der-Dennis]

Hallo Kalk,

Taschenrechner sehen auch gar nicht aus wie eine Tasche!! ;-)

Ja, Taschenmesser und Taschentücher auch nicht. Und nun?

es gibt Taschenmessertaschen und Taschentüchertaschen!

Gruß
Dennis

[Tabellenkalk]

Hallo,

es gibt Taschenmessertaschen und Taschentüchertaschen!

ja, aber die Messertasche ist gar nicht scharf und in die Tüchertasche hab ich auch lange nicht mehr reingeschnäuzt!

Gruß
Kalk

[Der-Dennis]

Hallo Kalk,

ja, aber die Messertasche ist gar nicht scharf und in die Tüchertasche hab ich auch lange nicht mehr reingeschnäuzt!

messerscharf erkannt, dass schnäuzende Schnauzer zum schnauzen weder Schnäuzer noch Schnauztüchertaschen brauchen.

[Gunnar Bittersmann]

@@Der-Dennis

Nein. Dein Taschenrechner zeigt sowas wie 0,03174603174603 an.

Nein. (der von mir auf dem Handy benutzte Taschenrechner)

Das ist kein Taschenrechner – schon gar nicht „auf“ deinem Handy –, sondern eine schon recht umfangreiche Webapplikation.

Doch. (mein sozusagen „analoger“ Taschenrechner; siehe Seite 12)

Die Anführungszeichen hätten um „Taschenrechner“ gehört. Auch dieser Rechner ist nicht das, was man gemeinhin unter Taschenrechner versteht.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Die Anführungszeichen hätten um „Taschenrechner“ gehört. Auch dieser Rechner ist nicht das, was man gemeinhin unter Taschenrechner versteht.

Zumindest in diesem Fall verstößt er nicht gegen die Einstufung als WTR durch das IQB, dort Hinweise zur Verwendung von Hilfsmitteln (PDF).

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Die Anführungszeichen hätten um „Taschenrechner“ gehört. Auch dieser Rechner ist nicht das, was man gemeinhin unter Taschenrechner versteht.

Zumindest in diesem Fall verstößt er nicht gegen die Einstufung als WTR durch das IQB, dort Hinweise zur Verwendung von Hilfsmitteln (PDF).

Die Apple Watch ist auch eine Uhr.

Mit Betonung wahlweise auf „auch“ bzw. „Uhr“.

LLAP 🖖

[Der-Dennis]

Hallo Gunnar,

ich denke Dir wird auch niemand widersprechen, wenn Du „die Apple Watch ist eine Uhr“ sagst. Dann sollte es aber auch nicht falsch sein, wenn jemand „der Casio-Taschenrechner ist ein Taschenrechner“ sagt.

Gruß
Dennis

[Der-Dennis]

Hallo Matthias,

Die Anführungszeichen hätten um „Taschenrechner“ gehört. Auch dieser Rechner ist nicht das, was man gemeinhin unter Taschenrechner versteht.

Zumindest in diesem Fall verstößt er nicht gegen die Einstufung als WTR durch das IQB, dort Hinweise zur Verwendung von Hilfsmitteln (PDF).

das ist ein guter Hinweis. Aber ich denke, es gibt auch viele Taschenrechner, die zwar als unerlaubtes Hilfsmittel bei Prüfungen eingestuft sind, es sich aber dennoch um Taschenrechner handelt.

Gruß
Dennis

[Tabellenkalk]

Hallo,

Nein. (der von mir auf dem Handy benutzte Taschenrechner)

Das ist kein Taschenrechner – schon gar nicht „auf“ deinem Handy –, sondern eine schon recht umfangreiche Webapplikation.

Gibt es eigentlich irgendwo eine Angabe, wie groß "Wolfram Alphas Wohnzimmer" ungefähr ist?

Gruß
Kalk

[Der-Dennis]

Hallo Kalk,

Gibt es eigentlich irgendwo eine Angabe, wie groß "Wolfram Alphas Wohnzimmer" ungefähr ist?

wahrscheinlich deutlich größer als die meisten Wohnungen :-) Ich habe leider nichts aktuelles gefunden, im Blogpost zum Start (2009) steht, dass es sechs Standorte sind und „Two supercomputers, just about 10,000 processor cores, hundreds of terabytes of disks, a heck of a lot of bandwidth, and what seems like enough air conditioning for the Sahara to host a ski resort.“ Ich vermute, weniger wird es in 7 Jahren eher nicht geworden sein :-)

Gruß
Dennis

[Der-Dennis]

Hallo Gunnar,

Nein. Dein Taschenrechner zeigt sowas wie 0,03174603174603 an.

Nein. (der von mir auf dem Handy benutzte Taschenrechner)

Das ist kein Taschenrechner

hmm, eigentlich hätte ich Dir schon zugetraut, dass Du das auch ohne Smiley und lange Erklärungen verstehst. Vor allem weil Du normalerweise immer vorne mit dabei bist, wenn es um Veränderungen in Richtung mobiler Geräte geht. Aber gut, dann muss ich das nächste mal wohl doch wieder in den „Sendung mit der Maus“-Modus schalten ;-)

Zusätzlich noch dazu: Mein Smartphone ist für mich eher mein Taschenrechner als „der richtige“ Taschenrechner. Auf jeden Fall habe ich das Handy häufiger in meiner Tasche als „den Richtigen“. Und rechnen kann das auch! :-)

schon gar nicht „auf“ deinem Handy

Wieso nicht? „Dat hap isch auf'm Händy“. Bei Berliner Schnauze wird hier doch auch nicht gemeckert? ;-)

sondern eine schon recht umfangreiche Webapplikation.

Ernsthaft? ;-)

Doch. (mein sozusagen „analoger“ Taschenrechner; siehe Seite 12)

Die Anführungszeichen hätten um „Taschenrechner“ gehört. Auch dieser Rechner ist nicht das, was man gemeinhin unter Taschenrechner versteht.

„Gemeinhin“ = „Was Gunnar darunter versteht oder jetzt gerade verstehen will“?

Was ist denn ein Taschenrechner für Dich? Ich behaupte, das Ding ist ein Taschenrechner. Und außerdem bin ich mir ziemlich sicher, dass sich eine große Mehrheit findet, die sowas als Taschenrechner bezeichnet. Muss man nur mal kurz in diesem Internet nachsehen. Wobei ich natürlich nicht ausschließe, dass es Gruppen geben kann, die das anders sehen.

Sollte es der Diskussion dienlich sein: In der Wikipedia (ja, ich weiß, das muss nichts heißen, ist aber evtl. wenigstens ein Anfang) steht: „Ein Taschenrechner ist eine tragbare, handliche elektronische Rechenmaschine, mit deren Hilfe numerische Berechnungen ausgeführt werden können.“

Aber jetzt mal ganz im Ernst. Wo ist das Problem? Dass ich „nein, sehe ich anders“ gesagt habe? Dein Posting liest sich jedenfalls ziemlich patzig. Kann aber auch sein, dass ich da gerade Deine Schnauze (bevor das hier falsch rüberkommt: Berlinerisch = „Schnauze mit Herz“) nicht richtig einordne.

Gruß
Dennis

[Gunnar Bittersmann]

@@Der-Dennis

„Gemeinhin“ = „Was Gunnar darunter versteht oder jetzt gerade verstehen will“?

Nein. „Gemeinhin“ = „Was außerhalb dieser Filterblase darunter verstanden wird“.

Nur weil wir vielleicht in derselben Filterblase leben, heißt das nicht, dass das die große weite Welt wäre.

Was ist denn ein Taschenrechner für Dich?

Ohne zusätzliche Attribute so’n normales Dingens mit Plus und Minus. Von mir aus auch mit Winkel-, Potenz- und Logarithmusfunktionen. Aber nichts programmierbares, nichts mit Grafikdisplay für Funktionsplots u.a. Schnickschnack.

Dein Posting liest sich jedenfalls ziemlich patzig.

Wenn du mir Wolfram Alpha als Taschenrechner verkaufen willst, hab ich wohl allen Grund dazu. ;-)

LLAP 🖖

[Der-Dennis]

Hallo Gunnar,

Nein. „Gemeinhin“ = „Was außerhalb dieser Filterblase darunter verstanden wird“.

Nur weil wir vielleicht in derselben Filterblase leben, heißt das nicht, dass das die große weite Welt wäre.

ach komm schon :-) Das mit der Filterblase ist richtig, das ist tatsächlich häufig ein Problem, aber doch nicht in diesem Fall hier, oder? Und nein, tiefster Urwald o.ä. zählt nicht, da würden auch andere Modelle nicht erkannt werden.

Mal unabhängig davon, dass ich das Ding nicht besonders toll finde und das nur aus der Schublade geholt hab, weil ich wusste, dass das auch eine Periode anzeigt (und ich normalerweise den Casio fx-85ES benutze, der mir mein Studium über treue Dienste erwiesen hat; der sieht so ähnlich aus wie der andere, kann aber weniger):

Damit alle wissen worum es geht, so hier sieht das angesprochene Ding aus ^[1]:

Und jetzt mal die Gründe, warum ich sowas als Taschenrechner bezeichne. Und danach erklärst Du mir die Filterbubble ;-)

• Für mich sieht das Ding wie ein Taschenrechner aus ;-)
• Casio ist ein bedeutender Hersteller für Taschenrechner (wen gibt es da noch so? HP, Sharp, TI, dann hört es bei mir was die Größe des Herstellers angeht schon auf); und dieser Hersteller für Taschenrechner bringt nun ein Gerät auf den Markt, das er selbst als Taschenrechner bezeichnet
• Geht man in einen Elektronikmarkt oder ähnliches, liegt dieses Gerät im Regal für Taschenrechner aus
• Sucht man im Internet, findet man (oder nur ich?) ausschließlich Händler, die dieses Gerät als Taschenrechner anpreisen und zum Verkauf anbieten
• Das Ding taucht in etlichen Tests für? Genau, Taschenrechner auf
• Es ist auf etlichen Listen von Schulen und Unis in der Kategorie „Taschenrechner“ gelistet
• Wenn Du Dich mit so einem Teil auf die Straße stellst und willkürlich Passanten ansprichst, was das sei, wirst Du mit großer Wahrscheinlichkeit „Wat willst Du denn? Willste mich für blöd verkaufen? ‘n Taschenrecher natürlich“ oder ähnliches als Antwort bekommen

So, ich hoffe das reicht :-) Und jetzt freue ich mich auf die Filterblase. Im Anschluss kannst Du dann bitte auch noch erklären, wie das mit den kleinen weißen Mäusen ist, die die Welt beherrschen. Ich suche mir schon mal ein Handtuch ;-)

Was ist denn ein Taschenrechner für Dich?

Ohne zusätzliche Attribute so’n normales Dingens mit Plus und Minus. Von mir aus auch mit Winkel-, Potenz- und Logarithmusfunktionen. Aber nichts programmierbares, nichts mit Grafikdisplay für Funktionsplots u.a. Schnickschnack.

Ja, gut, kann ich nachvollziehen. Außer Integralrechnung kann der aber auch nichts weiter, auch nicht sowas wie Funktionsplots. Diese „grafischen Displays“ sind eh Müll. Die sind nur für die nachfolgenden Generationen, die wegen der modernen Technik keine Klammern mehr setzen können ;-) Nein, quatsch, so schlimm ist es nicht. Aber diese Displays taugen wirklich nichts: Man braucht ewig, um da was einzugeben, wenn man das nutzt. Außerdem ist ganz schnell der Speicher voll, man kann nichts mehr eingeben und wieder von vorne anfangen. Und erkennen kann man auch nichts, „soo grafisch“ sind die nämlich nicht. Das sind eigentlich nur zwei- bis vierzeilige (?) Displays wie man sie auch von „Deinem“ Taschenrechner kennt. Ich brauche und nutze das jedenfalls nicht. Dürfte aber mittlerweile bei den meisten neueren Modellen Standard sein. Das einzige, was ich selbst tatsächlich als praktisch empfinde, ist das Umschalten zwischen Dezimal- und Bruchdarstellung.

Dein Posting liest sich jedenfalls ziemlich patzig.

Wenn du mir Wolfram Alpha als Taschenrechner verkaufen willst, hab ich wohl allen Grund dazu. ;-)

Ich finde das tatsächlich gar nicht so abwegig, wenn man das von einem Mobiltelefon aus aufruft. Auch wenn das vorher tatsächlich nicht ganz ernst gemeint war und ich Dir deshalb noch zusätzlich einen „echten Taschenrechner“ dazu geliefert habe ;-) Aber gut, der Punkt geht an Dich.

Gruß
Dennis

---

1. DerComputerChecker CC BY-SA 3.0, via Wikimedia Commons ↩︎