[Vienna-pm] [OT] Rundungsverhalten von Perl

Peter J. Holzer hjp-vienna-pm-list at hjp.at
Thu Oct 23 11:29:23 CDT 2003


On 2003-10-23 17:18:32 +0200, Thomas Klausner wrote:
> On Thu, Oct 23, 2003 at 04:40:40PM +0200, Christian Schoeller wrote:
> 
> > 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:
> > 
> > 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?
> 
> ich denke mal das modulo nur bei ganzen Zahlen Sinn macht (allerdings bin
> ich kein (echter) Mathematiker..)

Mathematisch ist der Perl- bzw. C-Operator % eh nur vage mit den "Ganzen
Zahlen modulo n" verwandt. Es gibt in C übrigens auch eine Funktion
fmod:

    SYNOPSIS
	   #include <math.h>

	   double fmod(double x, double y);

    DESCRIPTION
	   The  fmod()  function computes the remainder of dividing x
	   by y.  The return value is x - n * y, where n is the  quo­
	   tient of x / y, rounded towards zero to an integer.

Für FP-Werte diese statt dem Operator % zu verwenden, wäre technisch
kein Problem.

> Der Grund fuer den integer context von modulo ist wohl der, das Runden von
> floating point numbers irgendwie schwierig ist (wegen der Prezision und so..)

So schwierig ist es (wenn man auf ganze Stellen runden will) eigentlich
nicht: Ist das nächste Bit 0 wird abgerundet, ist das nächste 1 wird
aufgerundet, außer die folgenden sind alle 0, dann wird zur nächsten
geraden Zahl gerundet. Das lässt sich in HW einfach implementieren und
dürfte wohl in allen halbwegs aktuellen Prozessoren drin sein. 

Der Grund, warum das nicht gemacht wird, dürfte eher ein historischer
sein: C macht's auch nicht. 

Wobei wir da ja jetzt eigentlich zwei Dinge haben, die C nicht macht:

1) Remainder-Operationen auf FP-Werte. Keine Ahnung, warum C das nicht
    macht. Möglicherweise war die Operation Anfang der 70er-Jahre nicht
    üblicherweise in Hardware implementiert. (C hat eine starke Neigung,
    genau das als Operatoren darzustellen, was üblicherweise genau eine
    Maschineninstruktion ergibt, und alles kompliziertere in
    Library-Funktionen auszulagern).

2) Mathematisch korrektes Runden bei der FP-Integer-Konversion. Da
   mag wieder das HW-Argument eine Rolle spielen (der korrekte
   Algorithmus ist aufwendiger als simples Abschneiden), aber es ist
   auch konsistenter:

    int x = a / b;
   sollte das gleiche Ergebnis liefern, egal, ob a und b nun Integer-
   oder FP-Werte sind. Und bei Integer-Division wird nun mal immer
   abgerundet: 11 ist in 98 nur 8 mal enthalten, nicht 9 mal.

	hp

-- 
   _  | Peter J. Holzer    | We have failed our own creation and given
|_|_) | Sysadmin WSR       | birth something truly awful. We're just too
| |   | hjp at hjp.at         | busy cooing over the pram to notice.
__/   | http://www.hjp.at/ |       -- http://www.internetisshit.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20031023/be2c5676/attachment.bin


More information about the Vienna-pm mailing list