Re: [Gm2] REAL precision

[Gaius Mulley]

Andreas Fischlin <address@hidden> writes:

> I fully go along with this argumentation and want only to add that we are in
> exactly the same position. Using here compiler options may be a very good way
> out, giving possibly all the flexibility needed for everyone. Although that
> option would result in repercussions for any binary distributions, which would
> have to come with several library variants for standard numeric libraries.
>
> Regards,
> Andreas
>
> SiTex Graphics wrote:
>
>     Our applications store huge numbers of REALs and perform many, many
>     floating-point operations.  I'd like the handling of floating point
>     arithmetic to be as efficient as possible.  Doubling the storage
>     requirements for REAL is not an acceptable option for us.
>
>     I can of course search/replace and switch REAL-> SHORTREAL and
>     LONGREAL->REAL.  Then I have to add type casts for calls to the ISO
>     RealMath functions and any other standard libs that expect REAL
>     values.  Then we're still probably taking a performance hit for
>     double-precision computations in cases where the extra precision is
>     not needed.  Anyone else trying to port an application that makes
>     heavy use of REALs will face the same issues.
>
>     On the other side of the issue, is anyone actually using long double
>     arithmetic in GM2?
>
>     As a prospective user of GM2, support for existing code compatible
>     with other M2 compilers is far more important than a new feature that
>     I can't even consider using until our existing code compiles and
>     performs reasonably.
>
>     What about adding a LONGLONGREAL type for long double (with
>     LONGREAL=double and REAL=float)?  That convention would provide
>     compatibility with existing code and access to extended precision.  It
>     would also leave SHORTREAL available for some day supporting the new
>     16-bit half precision type.
>
>     -Scott

Hi Andreas and Scott,

thanks for the feedback on REAL/LONGREAL.  I've been looking into some
of the possibilities of changing gm2:


  (i)    leave things as they are.  Not really satisfactory as has been
         outlined above..  however at least we don't have
         incompatible binaries on the same system.

  (ii)   provide options to ./configure which determine the mappings
         of REAL/SHORTREAL/LONGREAL.  Could be done at some cost -
         particularly testing and future bug reporting become
         problematic.  In reality it passes the problem we are
         discussing to the distros..

  (iii)  provide command line switches (less bad than (ii) but we
         will need to double the copy of the libraries binaries).
         Bug reporting and maintainance will be harder.

  (iv)   change gm2 so that LONGREAL maps onto C double
                                REAL maps onto C float
                        LONGLONGREAL maps onto C long double

         the LONGLONGREAL is a little unsightly :-), and we loose
         SHORTREAL.  But at least the code only maps onto one set
         of data types.

  (v)    How about introducing more short library modules, so we have

         in PIM

         MathLib0.def    exports all REAL intrinsics
         SMathLib0.def   exports all SHORTREAL intrinsics
         LMathLib0.def   exports all LONGREAL intrinsics

         FpuIO           exports all REAL io routines
         LFpuIO          exports all LONGREAL io routines
         SFpuIO          exports all SHORTREAL io routines

         in ISO

         RealMath        exports all REAL intrinsics
         LongMath        exports all LONGREAL intrinsics
         ShortMath       exports all LONGREAL intrinsics

         for any math library provide a Long, Short, Real
         version.

         Finally provide a LegacyMath.def which contains the
         declaration

         DEFINITION MODULE LegacyMath ;
         TYPE
            REAL = SHORTREAL ;
         END LegacyMath.

         after which a user module only needs to have its imports
         changed to access the appropriate floating point routines
         and an additional FROM LegacyMath IMPORT REAL ;

         The advantage with this approach is that we do not have
         incompatible binaries on the same system from the same source
         files.  Also SHORTREAL library
         routines and intrisincs will be very efficient and require
         no conversions to higher precision counterparts.  The extra
         work involved is also pretty minor?

anyway I put this email out as food for thought, I'm not ruling out
(i)..(iv) but I would like to explore whether (v) is acceptable
or whether the volume of legacy code makes this impracticable

regards,
Gaius