• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Prozentrechner java

Steev

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
28.016
  • Thread Starter Thread Starter
  • #21
Ja Dexter, ich weiss ich habe hier wieder gar nichts gemacht, Ausser im Startbeitrag diesen simplen Code. Ich erwarte gar nichts, ihr könnt den Thread also auch verwenden für darüber reden, trotzdem Danke für obigen Code. Den Rest bringe ich selbst in Erfahrung wie ich das abspeichern muss usw :o
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.252
Fuer so triviale Testprojekte vielleicht. Aber schon wenn's "nur" um ein paar Millionen Werte geht, sieht das recht schnell anders aus. Von klassischen Funktion wie sin/cos/usw., die man dann im Zweifel selbst basteln muesste, mal ganz abgesehen.
Ich finde hier machst du Cherry Picking. Dein Argument für float/double war "Die Genauigkeit reicht meistens aus", ich schreibe dann "Die Geschwindigkeit von BigNum reicht auch meistens aus" und du schreibst obiges. Da kann ich jetzt ja nur schreiben: Wenn du vermeintlich exakte Werte ein paar tausend mal verrechnest, dann hast du ganz schnell etwas, das nicht mehr das ist was du erwartest, weil sich Rechenfehler aufsummiert haben. Vielleicht einigen wir uns darauf, dass programmieren schwierig ist? :D

Das haengt vom Problem ab. Bei realen Problemen moechte man ja oft eh nicht vergleichen ob zwei Werte exakt gleich sind, sondern, ob sie innerhalb einer gewissen Toleranz liegen. Die Toleranz haengt vom konkreten Problem ab, das auch definiert, in welcher Groessenordnung die Werte liegen werden. Es macht z.B. meist wenig Sinn, ueberall auf eine Nachkommastelle gerundete Werte auszugeben, aber dann intern zu pruefen, ob auch die 5 Stelle hinter dem Komma gleich ist (dann fragt sich der Nutzer, warum er zwei mal "42.0" sieht, die Anwendung aber steif und fest behauptet, die seien nicht gleich).
Ja, da stimme ich zu und ich denke das ist auch der wesentliche Punkt

Wie gesagt - es gibt sehr viele gute Gruende fuer Gleitkommazahlen. Effizienz, verfuegbare numerische Funktionen und nicht zuletzt die Unterstuetzung in der Sprache der Wahl (hier Java). Ebenso gibt es gute Gruende fuer BigNums mit garantierter Genauigkeit.
Sowohl Gleitkomma- als auch BigNum-Fixkommazahlen haben ihre Tuecken. Bei Gleitkomma-Zahlen ists die nicht garantierte Genauigkeit, aber auch bei BigNum-Fixkommazahlen muss man sich ja zumindest Gedanken machen, wie gross die erwarteten Werte werden und mit welcher Genauigkeit man rechnen moechte, sonst explodiert der Speicher ganz schnell. Das Gleitkommazahlen intrinsisch signifikante Stellen und nicht die Gesamtzahl der Stellen limitieren, ist Fluch und Segen zugleich. Je nach Anwendungsfall :)
Da stimme ich zu :).

Im allgemeinen halte die Wahrscheinlichkeit, sich mit Gleitkommazahlen Probleme einzuhandeln, fuer deutlich geringer, als die Wahrscheinlichkeit, durch unlesbaren Code Bugs zu produzieren (den BigDecimal ja schon fuer triviale Berechnungen produziert, siehe oben).
Hier stimme ich nicht so ganz zu, denn die Bugs von denen du sprichst sind sehr leicht zu identifizieren und fallen sehr schnell auf. Probleme mit fließkommazahlen treten ggf. erst auf wenn plötzlich die Zahl zu groß wird, man zu nah an 0 ist oder die Unterschiede zwischen zwei floats zu groß ist. Oder wenn man seine doubles doch letztendlich mehr verrechnet als man dachte und das Ergebnis schlicht nicht mehr stimmt.
Probleme mit floats/doubles sind im Prinzip allgegenwärtig zumal BigDecimal u.ä. aus den von dir genannten Gründen nicht immer zur Verfügung stehen:
Ich hatte 'mein' Beispiel gerade gesucht und leider nicht gefunden. Ein Raketensystem, das einmal am Tag neu gestartet werden muss, weil die Berechnung der Richtung fließkommabedingt mit der Zeit immer falscher wird.

Was wofuer sinnvoller ist, haengt vom Einzelfall ab. Hier ist double absolut kein Problem, mit BigDecimal macht man sich nur das Leben schwer.
Wenn jemand mit double Kryptografie machen moechte, wuerde ihm aber recht schnell klar, dass das so nicht geht :D
Ich würde da didaktisch argumentieren, wer jetzt nicht die Probleme von float/double verinnerlicht und im Zweifel lieber zu einem anderen Datentyp greift, der macht das dann später auch nicht mehr freiwillig.
 

Steev

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
28.016
  • Thread Starter Thread Starter
  • #23
Ihr könnt aber auch einen SQL laberthread aufmachen

--- [2020-11-03 10:54 CET] Automatisch zusammengeführter Beitrag ---

Edit FiAe thread

--- [2020-11-03 10:54 CET] Automatisch zusammengeführter Beitrag ---

Oder java
 

Brother John

(schein)heilig
Teammitglied

Registriert
1 Aug. 2013
Beiträge
235
Ein praktisches Beispiel für das Thema mit den Float-Ungenauigkeiten gabs vor kurzem im Morning Paper:

Available in open source, the resulting library is packaged in the Android Calculator app, with over 500 million installations. Since that change, “we no longer receive bug reports about inaccurate results

Für mich war das ein Augenöffner, Fließkomma-Ungenauigkeiten nicht mehr gar so schnell als »wird schon passen« abzutun.

Und kurz vorher gabs einen Artikel über ein Paper, das untersucht hat, wie einige wissensschaftliche Anwendungen mit den Fließkomma-Seltsamkeiten umgehen:

Lesen lohnt sich bei beiden.
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.252
Es ist wirklich prekär, dass semantische Korrektheit (exakte Rechnungen auf einer Teilmenge der rationalen Zahlen) mit so einem syntaktischen overhead einhergeht in Java.
Stack Overflow ist hier auch zuweilen irreführend. Da wird vorgeschlagen, floats gegen einen fixen Threshold zu vergleichen oder einfach long zu verwenden, aber alles *100 zu rechnen. Letzteres gerade in der OOP-Java kein gangbarer Weg und auch ein Weg, sich fiese Bugs einzufangen.
Sehr oft will man vermutlich gar keine BigDecimal, sondern einfach fixpoint Klassen wie oder

Sowas kann man sich in klein übrigens auch ganz toll als Übung selber bauen, Steev ;-). Die Klasse hat einfach intern einen integer und rechnet nur mit integer. Die Ausgabe wäre dann als String oder als float. Erstellt werden kann das ebenso als string oder float, wobei ein Fehler geworfen werden könnte, wenn der float gerundet werden muss. Das könnte man mit ein kleinwenig denkschmalz und Gleichheit prüfen.
 

Dr. M.

Weltmaschinenfahrer

Registriert
30 Juli 2018
Beiträge
144
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 :D
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.252
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.
 
Zuletzt bearbeitet:
Oben