From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9c86eb13dd395066
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: CRC in Ada?
Date: 1997/03/12
Message-ID: <dewar.858214844@merv>#1/1
X-Deja-AN: 225088894
References: <1997Mar2.220652@nova.wright.edu> <1997Mar5.131846.1@eisner>
 <5fmo1k$adm@mulga.cs.mu.OZ.AU> <1997Mar6.114441.1@eisner>
 <E6n850.3Ct@world.std.com> <1997Mar7.090814.1@eisner> <33206340.2616@bix.com>
 <1997Mar7.202252.1@eisner> <dewar.857828494@merv>
 <5fub2s$8k@fozzie.sun3.iaf.nl> <dewar.858095506@merv>
 <33269D56.6E8E@elca-matrix.ch>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-03-12T00:00:00+00:00
List-Id: <comp.lang.ada>


Mats says

<<This is another instance (the other being simple text IO, see other
threads going on) where Ada is by nature less effective than C, and the
sad thing is that it is not in the language itself but in standard
libraries that are over-featurized: who needs column and line numbers,
and a log function that is guaranteed to return exactly 0.0 when called
with exactly 1.0. I think such special needs are better addressed by
explicit coding: use an explicit line counter for that seldom occasion
where you need line numbers, or put the test for = 1.0 before you call
Log when you really need it to be a special case.

Robert replies:

It would be nice if there was a version of the numerics packages with
direct calls to the library and comparisons only for the cases where an
exception must be raised (such as Log of a negative value).>>

Actually this is catered for in the Ada 95 RM already. Accuracy requirements
must only be met if the numerics annex is supported, and it is perfectly
reasonable to have two versoins of the libraries, one for strict accuracy
and one where accuracy is not required.

It's something we might do for GNAT at some time. Right now, our customers
have much different concerns about performance, so worrying about elementary
function performance is not high on our lists (when it comes to optimizations
we are very much influenced by customer requirements [of the real kind, not
of the subjunctive "well maybe you would have more customers if xxx" kind :-)]

I would NOT be in favor of having a version that did not raise proper
exceptions as required in the RM, this is asking for portability problems.

Ada is unusual in specifying the accuracy semantics of floating-point in
general. This does cause some extra overhead which may be annoying to
those who want fast answers and don't care if they are accurate, so you
may lose some users there, but on the other hand, for those who DO want
to write reliable portable numeric code, Ada offers great advantages.

You can partly have your cake and eat it if the compioler supports the
strict and non-strict modes separately, but not completely!

As for the discussion of Text_IO, it is hard for me to believe that people
use Text_IO for anything other than very casual I/O. For example, it would
not have occurred to us to use Text_IO in the implementation of GNAT
itself (and we would not be using getchar if it was written in C). I really
have not seen the performance of Text_IO be a significant issue in real
large projects.

As I have said previously, I see no reason for not borrowing things from C
if it makes sense. I know that there are two possible reactions to this

  a) UGGGH! borrowing from C, what a horrible idea, GASP, SPLUTTER!

  b) well if you have to import getchar, you might as well write your
        whole million line application in C

I am afraid I have zero sympathy for either reaction. Neither makes any
sense at all. The first is borne of some over-fanatic Ada orientation,
the second is just a thinly disguised translation of an excuse!