[Vienna-pm] [OT] Rundungsverhalten von Perl

[LAUN Wolfgang]

Schönen Tag!

> -----Original Message-----
> From: Christian Schoeller [mailto:c_p_s at gmx.net]
> Sent: Thursday, October 23, 2003 4:41 PM
> To: vienna-pm at mail.pm.org
> Subject: [Vienna-pm] [OT] Rundungsverhalten von Perl
> 
> 
> Bei der Lektuere von "Einfuherung in Perl" fiel mir auf, dass die
> Programmiersprache meiner Wahl kein  mathematisches
> Rundungsverhalten anwendet, sondern falls noetig immer auf den 
> kleineren ganzzahligen Wert reduziert:

(Statt "mathematisch" sage ich hier lieber "kaufmännisch", wenn die
Regel angewendet werden soll, dass bei einem Betrag genau zwischen
zwei Rundingszielen das betragsmäßig größere genommen werden soll.)

CPU's/FPU's bieten oft mehrere Möglichkeiten, was bei einer Reduktion
der Genauigkeit geschehen soll. Z.B. Intel, wo das über ein FPU-Register
selektiert wird:
- Runden zur nächstliegenden "geraden" (s.u.) Maschinenzahl
- Aufrunden zur nächsten höheren Maschinenzahl ("ceiling")
- Abrunden zur nächsten niedrigeren Maschinenzahl ("floor")
- Abschneiden zur nächsten Maschinenzahl in Richtung 0
Das Runden einer Zahl, die genau zwischen 2 Maschinenzahlen liegt,
wird dabei nicht "kaumännisch" gemacht, sondern zu der Zahl, deren
geringstwertiges Bit 0 ist (z.B. 2.5 => 2, 3.5 => 4). Subtiles Motiv:
statistisch soll keine Richtung bevorzugt werden.

In Programmiersprachen wird bei einer Konversion Real
zu Integer oft Abschneiden verwendet (wenn nicht sowieso zwingend
explizite Funktionen wie round() oder trunc() zu verwenden sind).
Perl verhält sich hier wie C.

Wenn kaufmännisch sauber gerundet (und, ganz allgemein, gerechnet)
werden soll, so ist die Idee, Reals und sprintf zu verwenden,
überhaupt zum Scheitern verurteilt. Z.B.:
   $ perl -e 'printf "%.2f\n", 3.335;'
   3.33
Schuld ist nicht Perl oder printf, sondern die Tatsache, dass
3.335 als Real nicht genau dargestellt werden kann; die nächstliegende
Maschinenzahl ist 3.334999999...964... (Nicht umsonst gibt es in COBOL
oder Ada die Festkommazahlen...)

>
> Absatz "Modulo-Operator":
> # Beide Werte werden vorher auf ihren ganzzahligen Wert reduziert.
>
> Find' ich irgendwie merkwuerdig. Gibt es dafuer einen bestimmten
> Grund, den zu durschauen mir noch nicht moeglich war?

Wenn % (ähnlich wie in C; genau wie in C nur bei use integer) einmal
als Operator auf ganzzahligen Werten *definiert* ist, muss eben zu
Integer konvertiert werden. Selbstverständlich hätte auch eine
Definition von % mit Real-Operanden (analog fmod()) etwas für sich
gehabt. Das eine oder andere "merkwürdig" zu finden, ist m.E. eher
eine Frage der "Vorkenntnisse".

lg
Wolfgang

>
> Danke fuer Aufklaerung,
> Christian
> _______________________________________________
> Vienna-pm mailing list
> Vienna-pm at mail.pm.org
> http://mail.pm.org/mailman/listinfo/vienna-pm
>