Seite 2 von 2 ErsteErste 12
Ergebnis 26 bis 27 von 27

Thema: Prozentrechner java

  1. #26
    0.938 GeV
    Registriert seit
    Jul 2018
    Beiträge
    86

    Re: Prozentrechner java

    Danke auf fuer die Link, Bruder John! Interessant, aber auch nicht wirklich ueberraschend find ich.

    Der vielleicht wichtigste Punkt, der durch dein Zitat schoen unterstrichen wird, ist dass Gleitkomma-Arithmetik fuer Leute die damit nicht vertraut sind nicht gerade intuitiv ist. Ich vermute mal, "bug reports about inaccurate results" wird sich in vielen Faellen auf so was beziehen...
    Code:
    >>> 1e20-1 == 1e20
    True
    oder
    Code:
    >>> 0.8-0.1 == 0.7
    False
    aber beides ist kommt nicht unerwartet, wenn man sich einmal ueberlegt wie Gleitkommazahlen funktionieren.
    (Ich hab hier Python fuer die Beispiele hergenommen, aber das geht in jeder Sprache mit IEEE-doubles)

    Deshalb kann man auch nicht pauschal sagen, dass Gleitkomma-Ungenauitkeiten immer auf Bugs hindeuten. In der Hinsicht muss ich das Paper "Spying on the floating point behavior of existing, unmodified scientific applications" kritisieren:
    In jeder halbwegs komplexen Gleitkomma-Berechnung wird man irgendwo Praezision verlieren oder in gewissen Faellen NaN/Infinity produzieren. Wenn das von den Programmierern bedacht wurde und entweder keinen signifikanten Effekt auf das Endergebnis hat (verlorene Praezision) oder danach korrekt behandelt wird (NaN/Infinity), dann ist das vollkommen korrekt. Genau dafuer gibt's die speziellen nicht-endlichen Gleitkomma-Werte ja.

    Fixpoint-Berechnungen sind ebenso wenig davor gefreit, Praezision zu verlieren und entstehende Fehler aufzusummieren. Eher im Gegenteil, wenn man nicht massiv aufpasst, hat man das Problem schon sehr viel frueher als mit Gleitkomma-Zahlen (triviales Beispiel - Integer sind der einfachste Fall von "Fixpoint", und (1/10)*10 gibt auch mit Integern nicht 1).

    Das Problem ist evident, reelle Zahlen lassen sich bei begrenztem Speicher nicht in unbegrenzter Praezision darstellen. Auf einer Teilmenge mag das funktionieren, wobei die "Teilmenge" hier eine endliche, abzaehlbare Menge und insbesondere NICHT ein Intervall (z.B. [-1,1]) ist. Bei rationalen Zahlen kann man das mathematisch noch etwas schoener loesen weil sie grundsaetzlich abzaehlbar sind, bei reellen Zahlen beschraenkt es sich darauf allenfalls "einige ausgewaehlte" reelle Zahlen exakt darstellen zu koennen.

    Das bedeutet natuerlich nicht dass man nicht mit beliebiger (aber trotzdem beschraenkter!) Praezision rechnen kann, wenn man entsprechend mehr Speicher und Rechenzeit zuschiesst. Genau das machen die Big-Num-Bibliotheken im Endeffekt ja. Das geht in Gleitkomma-Darstellung genauso wie in Fixkomma-Darstellung.

    Aber das ist dann doch alles recht theoretisch, und ich kann mir ein paar Dinge vorstellen, die ich einem Java-Neuling eher beibringen wuerde
    Das mag aber auch mit meinem Physik-Hintergrund zusammenhaengen - frag mal einen Mathematiker, wie genau es Physiker mit der Mathematik nehmen ... wird schon gut gehen, im Zweifel nehme man eine sphaerische Kuh im Vakuum
    We do what we must, because we can.

  2. #27
    Bot #0384479 Avatar von BurnerR
    Registriert seit
    Jul 2013
    Beiträge
    4.924
    ngb:news Artikel
    3

    Re: Prozentrechner java

    Das ist theoretisch, aber wie schon ausgeführt von gerade zu globaler Tragweite. IT Studierende kriegen das deswegen zuweilen im ersten Monat des ersten Semesters beigebracht.
    Die Probleme mit Fließkomma sind mannigfaltig und schwer korrekt abzufangen. Als Physiker weißt du vermutlich, welche algebraische Struktur die reellen Zahlen ausprägen. Ich wüsste gerade jedoch selber nicht sicher aus dem Kopf, welche algebraische Struktur Fließkommazahlen ausprägen. Aber da diese nicht einmal abgeschlossen sind unter den Operationen offenbar nicht einmal jeweils eine Halbruppe.
    Aber um jetzt nicht zu theoretisch zu werden: Selbst wenn man versucht gewissenhaft zu sein ist es schwer abzuschätzen, ob kommutativität (also a+b = b+a) oder assoziativität ((a+b)+c = a+(b+c)) eine Rolle spielen könnten oder spielen werden. Erst recht ist es schwer, alle potenziellen Probleme mit float im Programmier-Alltag überhaupt im Kopf zu haben. Das geht eben so, wie du geschrieben hast oder Brother John dann aufgegriffen hatte: "Mal sehen... hmm, ja das passt schon". Aber genau so entstehen eben die Fehler auf die Brother John verweist.
    Geändert von BurnerR (09.11.20 um 09:33 Uhr)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •