BITTE helfen Sie uns HEUTE mit einer SPENDE
Helfen Sie das LibreOffice Forum zu erhalten!

❤️ DANKE >><< DANKE ❤️

> KEINE WERBUNG FÜR REGISTRIERTE BENUTZER!<
Ihre Spende wird für die Deckung der laufenden Kosten sowie den Erhalt und Ausbau 🌱 des LibreOffice Forums verwendet.
🤗 Als Dankeschön werden Sie im Forum als LO-SUPPORTER gekennzeichnet. 🤗

rechnet Calc falsch?

CALC ist die Tabellenkalkulation, die Sie immer wollten.
newbie-01
Beiträge: 19
Registriert: Mo 2. Apr 2018, 07:21

Re: rechnet Calc falsch?

Beitrag von newbie-01 » Di 17. Apr 2018, 08:25

Also das Thema ist weitgehend gelöst,

ich lege aber Wert auf die Feststellung daß ich NICHT! vorgeschlagen habe calc zu automatischen Rundungen zu überreden, denn

das ist völlig überflüssig, calc 'rundet' von ganz alleine sobald es einen 'Überlauf' seiner 'double?' Werte hat,

ich habe lediglich vorgeschlagen das etwas sinnvoller zu gestalten.

Und natürlich weiß ich das Einstein die Relativitätstheorie vor mir entdeckt hat, und Newton die Schwerkraft, ich wundere mich nur manchmal wieviel eigentlich nötige Weisheit im Alltag nicht verbreitet ist und mische das gerne mal etwas auf.

Manchmal hilft es Leuten die ähnlich denken, suchen oder graben Irritationen einzuordnen und schnell(er) an ihren Projekten weiterarbeiten zu können ... manchmal spammt es auch nur das www zu ... mit dem Problem bin ich aber in guter Gesellschaft ...

b.G.



newbie-01

Benutzeravatar
RPP63
Beiträge: 117
Registriert: Sa 21. Apr 2018, 09:33

Re: rechnet Calc falsch?

Beitrag von RPP63 » Do 14. Feb 2019, 14:45

Moin newbie!
Du philosophierst hier zwar nett, solltest aber erst einmal Grundlagenforschung betreiben:
Es gibt gewaltige Unterschiede zwischen:
  • Anzeige einer Dezimalzahl in der Zelle
  • Zellenformat
  • runden per =RUNDEN()
Schreibe in eine Zelle mit Standardbreite =1/7

Wenn Du jetzt schrittweise die Breite verringerst, wirst Du feststellen, dass LO den angezeigten Wert rundet.
(der eigentliche Wert ändert sich natürlich nicht!)

Vergibst Du ein benutzerdefiniertes Zahlenformat wie 0,00000 dann ändert sich die Anzeige, nicht jedoch der Wert!
(kann man leicht nachvollziehen, wenn man in eine breite Nachbarzelle =A1 eingibt und das Zahlenformat auf 0,000000000000 ändert)

Wenn Du hingegen =RUNDEN(1/7;5) eingibst, sind die Nachkommastellen ab der 6. Zahl unwiederbringlich weg!

Da die Gleitkommaproblematik erst ab ca. der 12. Stelle greift, kannst Du ohne merkbaren Genauigkeitsverlust auf 10 Stellen runden.

Oder Du nimmst Matlab (oder gleich den Windows-Taschenrechner, denn der kann 32 Stellen Genauigkeit :o ).

Gruß Ralf
Ein Feedback auf eine gegebene Lösung tut nicht weh und zeigt Querlesern, dass das Problem gelöst ist.

Pit Zyclade
Beiträge: 2674
Registriert: Mo 12. Nov 2012, 16:59

Re: rechnet Calc falsch?

Beitrag von Pit Zyclade » Fr 15. Feb 2019, 17:26

newbie-02 hat geschrieben:
Fr 15. Feb 2019, 16:32
die Zahlen 'richtig' lassen und nur durch die Anzeige / den Ausdruck zu runden ist für Rechnungsformulare etwas kritisch, Finanzamt und Kunden wollen immer daß die Ergebnisse mit einem Taschenrechner überprüfbar sind, und wenn dort - wegen Anzeigerundung von 10/7 - steht 1,43 * 35 = 50,00, ihr Taschenrechner aber 50,05 ausrechnet haben die ein Problem ...
Das ist so nicht völlig richtig. Wenn man mit anderen Institutionen nämlich vergleicht, stellt man fest, dass die Rundung oft nicht erst am Ende der Rechnung, sondern bereits vorher an irgendeiner Stelle erfolgt. Hinzu kommt, dass die Regel Auf- oder Abrunden scheinbar auch nicht der eigenen Logik oder dem kaufmännischen Bewußtsein folgt. So jedenfalls ergeht es mir immer, wenn ich meine Rente (minus den Abzügen) nachrechne. Um einen Cent stimmt sie dann fast nie.
(Klar man kann ja erst den Krankenkassenbeitrag runden, dann den Pflegebeitrag und dann erst abziehen oder erst alles abziehen und erst dann runden)
LO 7.5.8.2 (X86_64) / AOO 4.1.14 / Windows 11 64bit
Problem gelöst? Dann bitte im Betreff der ersten Nachricht [gelöst] voranstellen.

newbie-03
Beiträge: 18
Registriert: Sa 14. Dez 2019, 12:49

Re: rechnet Calc falsch? [solved]

Beitrag von newbie-03 » Sa 14. Dez 2019, 14:32

nochmal so als Nachtrag:

die in LO calc standardmäßig verwendeten Werte sind aufgrund Beschränkungen der Speicherung - 'Repräsentation' - nur auf 16 Stellen genau (solange keine Nachkommastellen oder Exponentialdarstellungen nötig sind, bei denen schrumpft die Genauigkeit auf 15 Stellen), und richtig 'genau' sind sie auch nicht, sondern angenähert durch Binärwerte. Dadurch gibt es 'Überhänge' in der 17. bzw. 16. Stelle die bei Rechnungen zu Fehlern führen können wo dann in der 16 Stelle mal 1 zuviel oder zuwenig auftaucht gegenüber dem was man 'erwartet'.

Beispiel:
9223372036854780,00000000000000000000 minus 6 gibt
9223372036854780,00000000000000000000 während minus 7
9223372036854770,00000000000000000000
ergibt.

Fies bzw. irritierend ist daß man die Anzeige solcher Zahlen auf z.B. 20 Nachkommastellen aufblasen kann ... wozu dann einfach Nullen angehängt werden. Die sind 'fake zeros', und gerechnet wird mit etwas anderem, nämlich dem signifikanten vorderen Teil des Wertes, der 'gemeine dume user' - also ich - denkt bei Anzeige von Zahlen die auf 0000 enden nicht unbedingt sofort daran daß in der Stelle davor! Rundungsfehler oder Repräsentationsfehler zuschlagen können.

also


b.G.



b.

newbie-03
Beiträge: 18
Registriert: Sa 14. Dez 2019, 12:49

Re: rechnet Calc falsch?

Beitrag von newbie-03 » Mo 22. Feb 2021, 09:58

nochmal so als Nachtrag:

also das Thema ist komplexer als ich dachte, wahrscheinlich sogar komplexer als manche 'Profis' sich vorstellen ... ich bin aber einer Lösung nahe die calc wesentlich verbessern wird ... leider mußte ich mich dazu erst jahrelang - wirklich jahrelang - durch Fehler und Halbwahrheiten hindurchbeißen,

nach derzeitigem Stand ... der sich noch ändern kann ... ist / sind:

1. die von mir als 'glatt' angenommenen Werte vielfach nicht glatt, wahrscheinlich da sie mit round(xyz;2) erzeugt wurden und calc in 'alten' Versionen Fehler beim Runden macht, ab etwa 7.1 ist das besser, ob endgültig richtig muß noch geprüft werden,
(tool zum Überprüfen: mit '=rawsubtract("Wert!";"Ganzzahlteil von Wert")' kann man viele solche kleinen Abweichungen sichtbar machen)
(leider bin ich für meine 'echte Arbeit' auf alte Versionen angewiesen, alles nach 6.1.6.3 ist wieder extrem langsam wenn man zu viele Kommentare in einer Datei hat :-( )

2. es ein Unterschied ob 'große' Werte ab 2^53 'granulär' werden oder kleine Werte mit Nachkommaanteil bei der Umwandlung ins Binärformat 'endlos' werden und deshalb kleine Rundungsfehler 'kassieren',

3. und noch etwas anderes ob die Werte ungenau sind oder sich diese Abweichungen bei Rechenoperationen 'vergrößern', (Addition kann die Fehler addieren und sie können sichtbar werden, Multiplikation soll 'safe' sein aber mir ist neulich ein Gegenbeispiel über den Weg gelaufen, Division soll safe sein habe ich noch nicht intensiv geguckt, Subtraktion mit 'cancellation' bei Verrechnung zweier ähnlich großer Zahlen ist der! 'blow up' für solche Fehler,)

4. wäre für die kleinen Werte und Berechnungen und insbesondere gegen die 'cancellation' 'automatisches Runden' hilfreich und sinnvoll, wird aber von der Entwickler community (insbesondere @Mike Kaganski) bisher nicht gewollt, einerseits wegen befürchteter 'performance impacts', andererseits weil es Berechnungen mit komplizierteren Zahlen wie z.B. pi() stören könnte,

ich wühle mich da mal weiter hindurch, ich halte es für wahrscheinlich daß calc - und andere Programme - demnächst auch mit Gleitkommazahlen 'decimal safe' werden können, wer dazu helfen kann oder möchte darf mir gerne 'privat' mailen,

beste Grüße,



b.

An alle, die das LibreOffice-Forum nutzen:


Bitte beteiligen Sie sich mit 7 Euro pro Monat und helfen uns bei unserem Budget für das Jahr 2024.
Einfach per Kreditkarte oder PayPal.
Als Dankeschön werden Sie im Forum als LO-SUPPORTER gekennzeichnet.

❤️ Vielen lieben Dank für Ihre Unterstützung ❤️

Antworten