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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8c424d8135e68278 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-22 08:59:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!fr.usenet-edu.net!usenet-edu.net!enst!enst.fr!not-for-mail From: "Steven Deller" Newsgroups: comp.lang.ada Subject: Math Update for Ada 2005 Date: Sat, 22 Dec 2001 11:56:46 -0500 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: avanie.enst.fr 1009040342 54870 137.194.161.2 (22 Dec 2001 16:59:02 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Sat, 22 Dec 2001 16:59:02 +0000 (UTC) To: Return-Path: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <9vvtrf$iqq$1@nh.pace.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:18246 Date: 2001-12-22T11:56:46-05:00 All the email about Math libraries reminded me of one of Ada 95's shortcomings. The IEEE math definitions have included NaN and Inf semantics for quite some time. Many (if not all) native platforms and many embedded platforms can support this. I have run into C++ and C code that uses these. Ada 95 does NOT support these. Interfacing Ada with C or C++ code that uses these can be quite a pain. How could we add these semantics into Ada 2005 without breaking past code and without *forcing* platforms to support this (if they don't do so easily). My thought was to have some sort of program wide values for floating point (settable?), with appropriate attributes to query the settings. Is that reasonable? Does anyone else want these semantics available? Suppose you have a subtype with narrow constraints (less than the 'Base range). Would Inf and NaN apply? I believe it would. I'd suggest that wherever raising constraint_error (for these types) would occur, instead the values would be set directly to "Inf" or "NaN" (consistent with IEEE semantics). Basically, if 'Base includes Inf and NaN values, then any subtype would include them as well. Or more to the point, any and all floating point types either would, or would not, include the values Inf and NaN (and appropriate semantics). Addition of these values would not require any additional constraint checking beyond that which is done now. Wherever code (without NaN and Inf) would have done a constraint check: if valhi_bound then raise constraint_error code (with NaN and Inf) would now be generated as if val /= NaN and valhi_bound then val := +Inf I seem to recall (?) that the "two" predicates are really just one test in IEEE arithmetic, i.e. I believe there is a way to check for something being "commensurate" and then comparing values, so the resulting code should not be any more complex or costly than current code. Typical application code could then look like: do lots of computations to compute one or more values if val = Inf then do things based on value going out of range including possibly explicitly raising constraint_error end if if val = NaN then ... The state could even be settable (perhaps at execution startup). In that case, there would have to be a test for the state (to decide whether to raise constraint_error or set a value to +/-Inf) though there might be some clever load time operations that could eliminate that test. This model can simplify code in many situations. When it is EXPECTED that something may go out of range and "that is ok", then raising an exception is not necessarily the right thing to do, particularly if the computation code "consumes" some inputs. The current Ada model *forces* an application to either "consume all data before computing", wrap an exception handler around every data "consumption", or have coupling between code and one "overall" exception handler so the handler knows how much data to "skip". None of these may be as satisfactory as: loop get data compute some get more data compute some get more data compute some if NaN or Inf values then output something else output something else end if end loop Regards, Steven Deller