FPC 2.2.4 erschienen

[monta]

Free Pascal 2.2.4 contains many bug fixes and some new features. The
main purpose of this release is to fix problems reported with FPC 2.2.2.

Please also see http://wiki.freepascal.org/User_Changes_2.2.4" onclick="window.open(this.href);return false; for a list
of changes which may affect the behaviour of previously working code, and
how to cope with these changes.

Some highlights are:

All:
* Experimental packages-installation tool

Packages:
* Added support for TIFF reading/writing in fcl-image
* Improvements and fixes in CHM support
* Fixed linking the gtk2-package with gtk versions above 2.13.4*

IDE:
* Added support for CHM help files

*Damit ist dieses Release auch das erste offizielle, welches die GTK-Probleme unter Ubuntu ab 8.10 (intrepid) behebt.

[Euklid]

Hallo,

ich halte eine Änderung aber für doch sehr problematisch, nämlich das neue Rundungsverhalten von FreePascal:

http://wiki.freepascal.org/User_Changes ... t_rounding" onclick="window.open(this.href);return false;

Es macht doch wirklich überhaupt KEINEN Sinn, dass sowohl 1,5 als auch 2,5 auf 2 gerundet wird!
Weshalb sollen die geraden Zahlen beim Runden ein stärkeres Gewicht haben als die ungeraden Zahlen?!? Das ist mathematisch NICHT korrekt und sorgt sicherlich nur für Verwirrungen bei allen Programmen, die den round-Befehl verwenden.

Als Grund wird Delphi-Kompatibilität angegeben. Mag zwar sein, dass Delphi tatsächlich derart unmathematisch rundet. Aber der FreePascal-Compiler muss diesen Unsinn doch nicht übernehmen? Wofür gibt es denn einen Delphi-Mode?

Viele Grüße, Euklid

[Hitman]

Ganz im Gegenteil: was du meinst (das "alte" Verhalten) ist das kaufmännische Runden, nicht das mathematische. Siehe auch:
http://de.wikipedia.org/wiki/Kaufm%E4nn ... he_Rundung" onclick="window.open(this.href);return false;

(irgendwie rafft das Forum die URL nich - einfach Copy & Pasten )

[Eb]

Ich muss gestehen, dass ich das neue Rundungsverhalten spontan als verspäteten Aprilscherz angesehen habe.

Nach dem Lessen des Wikipedia-Artikels wird das Verhalten zwar verständlich,
leider passt es aber mit dem im Mathematikunterricht (auch heute noch) vermittelten Wissen nicht zusammen.

Ich würde es auch als mathematisch nicht korrekt betrachten, wenn gerade und ungerade Zahlen verschieden behandelt werden.

Soll ich jetzt vielleicht, um das von mir (und geschätzten 99% der deutschen Bevölkerung) erwartete Verhalten zu erreichen, vor jeder Rundung erstmal 0.00000001 dazuaddieren?

[Hitman]

In dem Artikel wird doch (nachvollziehbar wie ich finde) erklärt, warum das gemacht wird: der Statistik wegen. Beim Runden betrachtest du doch 9 Ziffern (1 bis 9, 0 ist ja schon rund). Davon ist 5 ungünstiger Weise genau die Mitte. Rundest du da nun immer auf, würdest du nur 4 von 9 abrunden - du hast von Abrunden zu Aufrunden also ein Verhältnis von 4 zu 5. Da sollte einleuchten, dass das eine Verzerrung darstellt. Rundest du hingegen in solchen Fällen immer in Richtung der geraden Zahlen, rundest du (statisch gesehen) gleich oft auf und ab - also verzerrungsfrei. Sicher wird das im Matheunterricht normalerweise nicht so gelehrt, das macht es aber nicht falsch. Und seit wann ist das Schulwissen das Maß aller Dinge?

Ach und noch was: diese Änderung steht im Changelog ganz klar unter Non-x86 and non-linux/ppc64 systems - auf anderen Systemen war das Verhalten also anscheinend schon so.

[Eb]

Der Artikel erklärt das absolut nachvollziehbar.
Auch der Grund (für die Statistik) leuchtet völlig ein.

Aber wenn in einem Programm so gerundet wird:
1,50 EUR auf 2 EUR
2,50 EUR auf 2 EUR
3,50 EUR auf 4 EUR

Den Anwender möchte ich sehen, der das richtig findet - ich gehöre nicht dazu

[Hitman]

Wie gesagt macht Delphi und auch FPC (auf x86) das schon seit jeher so. Bisher hat sich keiner beschwert. Wieso spielt das jetzt ausgerechnet auf non-x86 eine Rolle?
Dein Beispiel ist zudem ziemlich konstruiert - wann rundet man Cent-Beträge einfach weg? Das allein - egal in welche Richtung - würde mich als Anwender stören
Aber selbst wenn nich: rechne mal damit --> 1,5 + 2,5 + 3,5 = 7,5 ... mit dem mathematischen Runden hätten wir also 2 + 2 + 4 = 8 ... schon ziemlich nah dran. Beim kaufmännischen Runden hätten wir jetzt 2 + 3 + 4 = 9 ... finde bitte den Dienstleister/Kreditinstitut/Händler/whatever, der das mitmacht (Oder wenns ums Bezahlen geht, den Kunden, der das mitmacht ....)

[Euklid]

Hitman: Danke für den Link! Habe das verzerrungsfreie Runden bisher nicht gekannt.

Beim Runden betrachtest du doch 9 Ziffern (1 bis 9, 0 ist ja schon rund). Davon ist 5 ungünstiger Weise genau die Mitte. Rundest du da nun immer auf, würdest du nur 4 von 9 abrunden - du hast von Abrunden zu Aufrunden also ein Verhältnis von 4 zu 5. Da sollte einleuchten, dass das eine Verzerrung darstellt.

Die Verzerrung gibt es aber auch beim unverzerrten Runden: Hier rundet man mit den Endungen 5,6,7,8,9,0,1,2,3,4,5 immer auf gerade Zahlen, mit den Endungen 6,7,8,9,0,1,2,3,4 (d.h. 2 weniger) auf ungerade Zahlen. D.h. es findet eine Verzerrung hin zu geraden Zahlen statt und dieses Problem ist somit durch die durchaus umständliche und wenig verbreitete "unverzerrte" Rundungsmethode NICHT gelöst. Offenbar haben beide Methoden ihre Nachteile, welche in Euren Beispielen sehr deutlich werden.

Dein Beispiel ist zudem ziemlich konstruiert - wann rundet man Cent-Beträge einfach weg?

Dies trifft aber auch auf dein Beispiel zu

... und weil wir alle schonmal dabei sind, möchte ich ein konstruiertes Beispiel nachlegen:
1,5 - 2,5 + 3,5 = 2,5
mathematisch ("unverzerrt") gerundet: 2 - 2 + 4 = 4
kaufmännisch gerundet: 2 - 3 + 4 = 3

Was würden die Dienstleister/Kreditinstitute/Händler/whatever dazu wohl sagen?

Das unverzerrte Runden bringt also genauso im konstruierten Spezialfall einen Vorteil, wie das kaufmännische Runden im konstruierten Spezialfall näher an der Wirklichkeit ist. ABER: Das kaufmännische Runden wird an den Schulen gelehrt, das unverzerrte Runden ist weitgehend unbekannt. Von welchem Verhalten würde wohl der Durchschnittsprogrammierer ausgehen, wenn er die round-Routine verwendet?

[Hitman]

Was für ein Beispiel? Ich hab nur seins weitergerechnet
Letztlich sollte man sich doch fragen: wann rundet man überhaupt und spielt es dann noch eine Rolle, ob nun kaufmännisch oder mathematisch gerundet wird? Ein potenzieller Endanwender kriegt es im Normalfall nicht zu Gesicht. Mir fällt zumindest im Moment kein Fall ein, wo es wirklich relevant wäre.

Und (wie nun mehrfach gesagt): bisher hat es doch auch niemanden gestört, dass es so gemacht wurde. FPC hat das schon immer getan, Delphi auch, selbst in .NET ist es so: http://msdn.microsoft.com/en-us/library ... round.aspx" onclick="window.open(this.href);return false;
Bankers Rounding (also das "mathematische" oder "unverzerrte" Runden) ist nunmal Standard - auch wenn es nicht an der Schule gelehrt wird.

[af0815]

Notfalls kann man ja das Rundungsverhalten ja auf das umstellen, was man haben will. Wird ja auch bei den Infos erklärt.

[pluto]

wann rundet man überhaupt und spielt es dann noch eine Rolle, ob nun kaufmännisch oder mathematisch gerundet wird?

Eine Gute Fragen. Z.B. weiß ich das bei Rezepturen Umstellungen gerundet wird, wobei hier ist nur wichtig das das Verhältnis stimmt. Also Spielt es keine Rolle, wie jetzt gerundet wird. Aber das Ergebnis wird so oder so "Verfälscht" durch runden. Also Spielt das doch keine Rolle. Ob das nun für den Kunden ein Vorteil oder für den Verkäufer ein Vorteil bringt. Dann sollte man einfach die Kommastellen abschneiden und gut ist*G*

[Euklid]

Und (wie nun mehrfach gesagt): bisher hat es doch auch niemanden gestört, dass es so gemacht wurde. FPC hat das schon immer getan, Delphi auch[...].

Ok, dann würde es generell für Verwirrung sorgen, wenn sich das Verhalten des FPC plötzlich ändert. Kontinuität und Verlässlichkeit sind für Compiler sicherlich entscheidende Eigenschaften.

Zur Not kann man das Runden ja, wie im obigen Artikel erläutert, auf kaufmännisches Runden umstellen.

[Scotty]

...auch wenn es nicht an der Schule gelehrt wird.

Ich habe es richtig gelernt. (70-80er Jahre, Ostdeutschland)