Re: [Gm2] REAL precision

[Andreas Fischlin]

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


On Wed, Jun 24, 2009 at 7:58 AM, Andreas
Fischlin<address@hidden> wrote:
  

Dear Scott,

I fully agree that REAL = "IEEE single precision real" and LONGREAL = "IEEE
double precision real" is the approach most M2 implementations follow. Thus
I would therefore even argue that this should actually be the default and
REAL = double precision should be the option you have to request. But,
agreed, this argument depends on what one wants to accomplish with gm2:
Legacy code or modern, state-of-the-art implementation of a Modula-2. The
former calls for default is REAL single/LONGREAL double, the latter would
rather opt for leaving the defaults as they are now (if I all understood
correctly).

Regards,
Andreas



SiTex Graphics wrote:

Hi Gaius,

By default GM2 translates the REAL type as a double precision number.
Is there a way I can build the compiler with REAL=float, and
LONGREAL=double?  Or perhaps persuade you to make REAL=float the
default bahavior? That's been the convention for every other M2
compiler I've used...

Anyone else have a preference for REAL=float or REAL=double?

Also for Gaius: I sent a message on June 17 reporting a new problem
and inquiring about the status of an earlier bug report.  Did you
receive that message?

Thanks,
Scott


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


--

________________________________________________________________________
ETH Zurich
Prof. Dr. Andreas Fischlin
Systems Ecology - Institute of Integrative Biology
CHN E 21.1
Universitaetstrasse 16
8092 Zurich
SWITZERLAND

address@hidden
www.sysecol.ethz.ch

+41 44 633-6090 phone
+41 44 633-1136 fax

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


    

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

--

________________________________________________________________________
ETH Zurich
Prof. Dr. Andreas Fischlin
Systems Ecology - Institute of Integrative Biology
CHN E 21.1
Universitaetstrasse 16
8092 Zurich
SWITZERLAND

address@hidden
www.sysecol.ethz.ch

+41 44 633-6090 phone
+41 44 633-1136 fax

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

 

andreas_fischlin.vcf
Description: Vcard