Re: [Gm2] complex types

[Andreas Fischlin]

Tricky business. Let me state a couple of things:

1) IEEE 754 floating point is only defined for single (32) and double precision (64) reals.
2) 128 bit long reals are not abundantly available and indeed, there might be performance penalties for using it

I favor module variants over functions with different names. This gives optimal performance while retaining flexibility. E.g. a programer can write complicated algorithms with the same function names, using e.g. a client type Real. This gives code similar to this:

    FROM LongMathLib IMPORT Tan;

    TYPE  Real = LONGREAL;
    VAR x,y: Real;

    BEGIN
          y := Tan(x);

vs.

    FROM MathLib IMPORT Tan;

    TYPE  Real = REAL;
    VAR x,y: Real;

    BEGIN
          y := Tan(x);

In this spirit I have designed the following DEFs forming part of the 'Dialog Machine' and being backward compatible with PIM legacy:

________________________________________________________________________________

DEFINITION MODULE DMLongMathLib;

  (*******************************************************************

    Module  DMLongMathLib     ('Dialog Machine' DM_V3.0)

      Copyright (c) 1998-2006 by Andreas Fischlin and ETH Zurich.

    Purpose   Basic mathematical routines operating on
              type LONGREAL (cf. module DMMathLib).

    Remarks   On the Macintosh this module uses SANE
              throughout.

              This module belongs to the 'Dialog Machine'.


    Programming

      o Design
        Andreas Fischlin          16/01/1998

      o Implementation
        Andreas Fischlin          16/01/1998


    ETH Zurich
    Systems Ecology
    CHN E 35.1
    Universitaetstrasse 16
    8092 Zurich
    SWITZERLAND

    URLs:
        <mailto:address@hidden>
        <http://www.sysecol.ethz.ch>
        <http://www.sysecol.ethz.ch/SimSoftware/RAMSES>


    Last revision of definition:  16/01/1998  AF

  *******************************************************************)


  PROCEDURE LongSqrt  (x: LONGREAL):    LONGREAL;
  PROCEDURE LongExp   (x: LONGREAL):    LONGREAL;
  PROCEDURE LongLn    (x: LONGREAL):    LONGREAL;
  PROCEDURE LongSin   (x: LONGREAL):    LONGREAL;
  PROCEDURE LongCos   (x: LONGREAL):    LONGREAL;
  PROCEDURE LongArcTan(x: LONGREAL):    LONGREAL;
  PROCEDURE LongReal  (x: LONGINT):     LONGREAL;
  PROCEDURE LongEntier(x: LONGREAL):    LONGINT;

END DMLongMathLib.

________________________________________________________________________________

DEFINITION MODULE DMMathLib;

  (*******************************************************************

    Module  DMMathLib     ('Dialog Machine' DM_V3.0)

      Copyright (c) 1991-2006 by Andreas Fischlin and ETH Zurich.

    Purpose   Basic mathematical routines operating on
              type REAL (cf. module DMLongMathLib).

    Remarks   Macintosh implementation:
              ------------------------
              There are several variants of this module
              available: One is using SANE (slower but more
              accurate, since all calculations are actually made
              with 80 Bit reals [extended IEEE format]) and
              another, substantially more efficient version,
              which is bypassing SANE, i.e. is using a native 32
              Bit floating point arithmetic.  The latter is
              similar to a third, for utmost portability
              implemented variant (BatchDM) available.  The
              latter variant should yield the most portable
              results on any platform.  For more details see the
              SANE manual, Addison Wesley and module 'DMFloatEnv'.

              IBM PC implementation:
              ---------------------
              Portable, not necessary most efficient implementation
              provided.

              Sun (Unix) implementation:
              -------------------------
              Portable, not necessary most efficient implementation
              provided.

              There is also a companion module, named DMMathLF,
              available, which directly uses the mathematical
              coprocessor and provides optimally efficient
              algorithms.  However, the price to pay for this
              gain in efficiency is portability, since on some
              machines this code may not be executable if the
              required hardware component is missing.  Using the
              module 'DMMathLib' is always safe and should not
              cause portability problems, but it may not always
              be the most efficient solution.

              This module belongs to the 'Dialog Machine'.


    Programming

      o Design
        Andreas Fischlin          25/06/1991

      o Implementation
        Andreas Fischlin          25/06/1991


    ETH Zurich
    Systems Ecology
    CHN E 35.1
    Universitaetstrasse 16
    8092 Zurich
    SWITZERLAND

    URLs:
        <mailto:address@hidden>
        <http://www.sysecol.ethz.ch>
        <http://www.sysecol.ethz.ch/SimSoftware/RAMSES>


    Last revision of definition:  05/08/1991  AF

  *******************************************************************)


  PROCEDURE Sqrt  (x: REAL):    REAL;
  PROCEDURE Exp   (x: REAL):    REAL;
  PROCEDURE Ln    (x: REAL):    REAL;
  PROCEDURE Sin   (x: REAL):    REAL;
  PROCEDURE Cos   (x: REAL):    REAL;
  PROCEDURE ArcTan(x: REAL):    REAL;
  PROCEDURE Real  (x: INTEGER): REAL;
  PROCEDURE Entier(x: REAL):    INTEGER; (* Entier is similar to TRUNC,
                                         but truncates also negative x
                                         values to the smaller integral
                                         part. Ex.: Entier(-3.3) returns
                                         -4 where TRUNC(-3.3) is -3.  *)


  (*
    Simple random number generators, which return variates in
    ranges [0..upperBound] (RandomInt) resp. (0..1] (RandomReal).
    Don't use these generators for serious stochastic simulations!
    Their properties are not optimal. For better random number
    generators see the modules RandGen, RandGen0, RandGen1,
    RandNormal etc.
  *)
  PROCEDURE Randomize;
  PROCEDURE RandomInt(upperBound: INTEGER): INTEGER;
  PROCEDURE RandomReal(): REAL;

END DMMathLib.

________________________________________________________________________________


DEFINITION MODULE DMMathLF;

  (*******************************************************************

    Module  DMMathLF     ('Dialog Machine' DM_V3.0)

      Copyright (c) 1991-2006 by Andreas Fischlin and ETH Zurich.

    Purpose   Basic mathematical routines (as provided by module
              DMMathLib), but with a fast implementation, which
              uses possibly present floating point processors
              (numerical behavior may be hardware dependent).

    Remarks   Macintosh implementation:
              ------------------------
              Always requires the presence of a mathematical
              coprocessor.

              IBM PC implementation:
              ---------------------
              Portable, not necessary most efficient implementation
              provided.

              Sun (Unix) implementation:
              -------------------------
              Portable, not necessary most efficient implementation
              provided.

              This module directly uses the mathematical
              coprocessor which may render the code significantly
              faster.

              There are also companion modules named DMMathLib,
              which work on any machine, regardless whether there is a
              mathematical coprocessor actually present or not, thus
              offering optimal portability, eventually at the price of
              less efficiency.

              This module belongs to the 'Dialog Machine'.


    Programming

      o Design
        Andreas Fischlin          25/06/1991

      o Implementation
        Andreas Fischlin          25/06/1991


    ETH Zurich
    Systems Ecology
    CHN E 35.1
    Universitaetstrasse 16
    8092 Zurich
    SWITZERLAND

    URLs:
        <mailto:address@hidden>
        <http://www.sysecol.ethz.ch>
        <http://www.sysecol.ethz.ch/SimSoftware/RAMSES>


    Last revision of definition:  06/09/1995  AF

  *******************************************************************)


  PROCEDURE Sqrt  (x: REAL):    REAL;
  PROCEDURE Exp   (x: REAL):    REAL;
  PROCEDURE Ln    (x: REAL):    REAL;
  PROCEDURE Sin   (x: REAL):    REAL;
  PROCEDURE Cos   (x: REAL):    REAL;
  PROCEDURE ArcTan(x: REAL):    REAL;
  PROCEDURE Real  (x: INTEGER): REAL;
  PROCEDURE Entier(x: REAL):    INTEGER; (* Entier is similar to TRUNC,
                                         but truncates also negative x
                                         values to the smaller integral
                                         part. Ex.: Entier(-3.3) returns
                                         -4 where TRUNC(-3.3) is -3.  *)

  (*
    Simple random number generators, which return variates in
    ranges [0..upperBound] (RandomInt) resp. (0..1] (RandomReal).
    Don't use these generators for serious stochastic simulations!
    Their properties are not optimal. For better random number
    generators see the modules RandGen, RandGen0, RandGen1,
    RandNormal etc.
  *)
  PROCEDURE Randomize;
  PROCEDURE RandomInt(upperBound: INTEGER): INTEGER;
  PROCEDURE RandomReal(): REAL;

END DMMathLF.
________________________________________________________________________________

All this code can also be inspected at: 

    http://www.sysecol.ethz.ch/RAMSES

Notably

    http://se-server.ethz.ch/RAMSES/Objects/RMSModsByLayer.html#Dialog%20Machine


Regards,
Andreas


Michael Lambert wrote:

Hi Gaius,

On 15 Dec 2008, at 08:35, Gaius Mulley wrote:

I've followed PIM2, PIM3, PIM4 (for sqrt, exp, ln, sin, cos, tan,
arctan and entier).  However do you think it better to default to use
the LONGREAL versions and allow users to specify lower precision
variants if desired?

So in the case of tan we might have

PROCEDURE tan (x: LONGREAL) : LONGREAL ;
PROCEDURE tanr (x: REAL) : REAL ;
PROCEDURE tans (x: SHORTREAL) : SHORTREAL ;

given that LONGREAL, REAL, SHORTREAL are assignment compatible.
However they are not _expression_ compatible so this change will
probably break legacy code..

I would be inclined to stay with REAL functions and leave it to the programmer to apply explicit coercion when necessary.  Even with most modern systems using IEEE 754 floating point, the only guarantee is that

TSIZE(SHORTREAL) <= TSIZE(REAL) <= TSIZE(LONGREAL)

with emphasis on '='.  For example, on the Alpha these are 32/64/64 bits and I wouldn't be surprised if some platforms still implement 32/32/64.  Even for systems with 32/64/128, I don't know that the 128-bit floating point is done in hardware--performance could be important.

Michael



_______________________________________________
gm2 mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/gm2

--

________________________________________________________________________
Dr. Andreas Fischlin, Ph.D., Group Director

Terrestrial Systems Ecology
Institute of Integrative Biology: Ecology, Evolution, Infectious Disease
Department of Environmental Sciences, ETH Zurich

Address:
ETH Zurich, CHN E21.1
8092 Zurich, Switzerland

Phone: +41 44 633-6090 / Fax: +41 44 633-1136
http://www.sysecol.ethz.ch/Staff/af/
http://www.sysecol.ethz.ch/

     _/_/_/ _/_/_/ _/  _/
    _/       _/   _/  _/   Eidgenoessische Technische Hochschule Zuerich
   _/_/_/   _/   _/_/_/   Swiss Federal Institute of Technology Zurich
  _/       _/   _/  _/   Ecole polytechnique federale de Zurich
 _/_/_/   _/   _/  _/   Politecnico federale de Zurigo

             Make it as simple as possible, but distrust it!
________________________________________________________________________