Rundungsfehler in Numbers... *seufz*

[crossinger]

Ja, und er ist mir peinlicherweise laaaange gar nicht aufgefallen!

Man nehme: 2 Zeilen, 3 Spalten:

A : 15
B : 23
c : 4

und erstelle daraus ein Diagramm:

Wer findet den Fehler?

*J*

P.S.: Ich werde nie mehr lachen, wenn sowas bei bildblog.de als "Patzer" der Bildzeitung gelistet wird. Vielleicht nimmt die Redaktion Apples Numbers...

 

[Dinofelis]

Mein erster Beitrag hier

Eigentlich ist alles korrekt. Du zeigst im Diagramm nur die falsche Anzahl an Kommastellen.

Denn das Verhältnis Deiner Ausgangszahlen zu deren Summe wird bei Rundung auf Null Kommastellen korrekt wiedergegeben. Zufällig werden alle drei Zahlen eben aufgerundet, daher die Differenz zu Hundert.

Das hier gehört zwar eher in einen Spaß-Thread, aber trotzdem:

Vielleicht wird dann klar, dass es in der Mathematik immer wieder Probleme durch Annäherungen gibt.

Teile 10 durch 9, das ergibt 1,11...

Nehme das Ergebnis mal 9, das ergibt 9,99...

Upps, ein Rundungsfehler, und das ganz ohne Excel oder Numbers.

 

[crossinger]

Mein erster Beitrag hier

Na dann: Willkommen bei AT!

Das mit den Rundungen ist mir schon klar. Allerdings messe ich dem Rundungsproblem bei Diagrammen eine höhere Relevanz zu als bei Zahlenkolonnen. Die Summe "darf" hier einfach nicht >100 sein und ich erwarte eigentlich von einer Diagrammsoftware geeignete (automatische) Gegenmaßnahmen!

Wie auch immer: Beim nächsten Mal wird halt gegengeprüft, anstatt sich auf den Rechenknecht zu verlassen...

EDIT: Deine flapsige Antwort (sorry - nicht ernst gemeint! ) hat mich angespornt, noch ein paar Tests zu fahren. Getestet habe ich's jetzt auch mit OpenOffice 2.3.1 (Win) und Microsoft Office 2003 (Win). Ergebnis: OOo macht den gleichen Fehler, aber Excel 2003 korrigiert die Rundung (!) und meldet 54%/36%/10%

SO muss das sein!!!

*J*

 

[Dinofelis]

Wie auch immer: Beim nächsten Mal wird halt gegengeprüft, anstatt sich auf den Rechenknecht zu verlassen...

Das kannst du auch automatisch korrigieren.

Die Formel unten bringt alles in Ordnung wenn man sie zweimal verwendet (also in Spalte C und in Spalte D; Spalte D stimmt dann).

 

[crossinger]

Merci! Hätte ich aber gern automatisch... (siehe mein Edit oben!)

*J*

 

[Dinofelis]

Deine flapsige Antwort (sorry - nicht ernst gemeint!

Kein Problem, es ist ja nicht wirklich ein Fehler, sondern nur eine ungünstige Kombination aus Rundung und Anzeige der Kommastellen. Genau wie in meinem 9,99er Beispiel. In Excel ist wahrscheinlich genau der Mechanismus dazwischengeschaltet, den ich mit der Formel in meiner zweiten Antwort angedeutet habe. Solange iterieren bis die Summe gleich Eins ist.

Also ihr Numbers-Entwickler bei Apple, schwingt die Hufen

 

[vierundvierzig]

SO muss das sein!!!

Naja, was heißt hier: "So muss das sein!" Ich sehe ja ein, dass es in einem Tortendiagramm nur bis 100% geht. Aber woher soll denn nun Numbers wissen, welche Zahl es jetzt falsch runden soll? Wenn es das tun würde, wärst Du der erste, der sagt: "Warum rundet Numbers hier einfach irgendeine Zahl? Ich will das aber selbst bestimmen!" ... Also im Scherz mehr, nicht böse. Du weißt schon

Ich finde Numbers und OO machen alles richtig. Nur Excel ist da falsch und glaubt, der Benutzer wäre zu doof zum Addieren.

 

[crossinger]

Wenn es das tun würde, wärst Du der erste, der sagt: "Warum rundet Numbers hier einfach irgendeine Zahl? Ich will das aber selbst bestimmen!" ... Also im Scherz mehr, nicht böse. Du weißt schon

Du wirst lachen: Bevor ich diesen Thread startete, habe ich mir auch darüber Gedanken gemacht: Liegt es allein in meiner Verantwortung? Will ich "exakte" Zahlen, die in der Summe falsch sind? Mein (vorläufiges) Fazit war: Ein Kreis hat - im Gegensatz zu einzelnen Säulen o.ä. - eben eine feste Dimension, die 100% definiert. Und dann muss in meinen Augen das Programm zwingend dieses Korsett einhalten. Von daher bin ich immer noch der Überzeugung: Ja, der Eingriff von Excel ist in der daraus resultierenden Konsequenz "richtig".

*J*

 

[Dinofelis]

Ein Kreis hat - im Gegensatz zu einzelnen Säulen o.ä. - eben eine feste Dimension, die 100% definiert. Und dann muss in meinen Augen das Programm zwingend dieses Korsett einhalten.

Sehe ich im Fall von solchen Diagrammen auch so. Lieber falsch gerundete Werte, die als Summe Eins ergeben, als umgekehrt.

Man kann dem Einzelstück einer Torte in keiner Weise ansehen, auf wieviel Kommastellen genau es ist, man kann es nicht einmal nachmessen. Und darüber hinaus ist die Genauigkeit bei solchen Darstellungen eher zweitrangig. Es geht doch eher darum, auf einen Blick die Verhältnisse zu erkennen.

Aber jeder sieht sofort die Zahlen auf den Tortenstücken und jeder freut sich diebisch, wenn er dem Ersteller oder dem Programm einen "Fehler" unter die Nase reiben kann. Daher: Lieber ungenau im Wert aber in der simplen Addition der dargestellten Zahlen korrekt.

 

[crossinger]

Aber jeder sieht sofort die Zahlen auf den Tortenstücken und jeder freut sich diebisch, wenn er dem Ersteller oder dem Programm einen "Fehler" unter die Nase reiben kann.

Nee, ich freue mich nicht diebisch. Wie bereits im ersten Posting angedeutet: Dieses Diagramm wurde so wie es ist unkontrolliert veröffentlicht. Musste damals schnell gehen - und der Computer "rechnet" ja nicht falsch...

Immerhin habe ich es jetzt selbst entdeckt und korrigiert.

*J*

 

[Dinofelis]

Nee, ich freue mich nicht diebisch.

Ist schon OK.

Ich meinte eben *nicht* dich.

Du suchst ja nur nach einer Lösung, weil du die Reaktionen der sich diebisch-freuenden fürchtest.

 

[AgentSmith]

Sorry für's Ausbuddeln, aber ich hab diesen Thread gestern beim Suchen nach etwas zu Numbers zufällig entdeckt und als mir gerade folgender Artikel ins Auge sprang, dachte ich mir, den muss ich hier einfach posten.

 

[crossinger]

Moin,

danke - den kannte ich schon. Spannender fand ich dagegen neulich auf SpOn einen Artikel mit Tortendiagrammen, die ziemlich zweifelsfrei mit Numbers gemacht worden waren (Optik, Farbschattierung, etc.). Dabei stand dann ein Kommentartext "Summe weicht von 100 ab wegen Rundungsfehler" o.ä. - ich weiß den genauen Text nicht mehr. Auf jeden Fall hatten die offenbar mit dem gleichen Phänomen zu kämpfen. Obwohl es so leicht ist, das (optisch) zu korrigieren.

*J*

 

[Ikezu Sennin]

P.S.: Ich werde nie mehr lachen, wenn sowas bei bildblog.de als "Patzer" der Bildzeitung gelistet wird. Vielleicht nimmt die Redaktion Apples Numbers...

Ab jetzt werden sie das wohl tun...

 

[iPiet]

Teile 10 durch 9, das ergibt 1,11...

Nehme das Ergebnis mal 9, das ergibt 9,99...

Upps, ein Rundungsfehler, und das ganz ohne Excel oder Numbers.

Da muss ich als Angehöriger der Randgruppe mathematisch stark vorbelasteter mal arg widersprechen: 9,99... (Periode) ist ganz genau 1. Wenn man so will nur eine andere Schreibweise. Das hat was mit Grenzwerten von Folgen zu tun. Also kein Rundungsfehler, sondern nur eine falsche Lesart. Wenn man die Zahl nach zwei Stellen abschneidet, dann ist natürlich 9,99 nicht 10.

Ich habe meinen Studenten übrigens letztens in der Vorlesung ein Kuchendiagramm aus der Frankfurter Allgemeinen Zeitung gezeigt (leider habe ich keinen Scan). In dem Diagramm ging es auch um die Aufteilung von 100% und die haben es fertig gebracht insgesamt nur 95% Prozent zusammen zu bekommen. Will heißen: die Bild hat zwar ein Fehlerabo, andere Medien sind aber Fehler-Gelegenheitskäufer.

Im Allgemeinen kann ich nur raten, dass man jedwede graphische Darstellung von Daten penibel prüft, denn es gibt es ganze Reihe von Fehlerquellen, die zu einer verzerrten Darstellung führen können.