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,885dab3998d28a4 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Ariane 5 failure Date: 1996/10/15 Message-ID: #1/1 X-Deja-AN: 189691083 references: <96101416363982@psavax.pwfl.com> organization: New York University newsgroups: comp.lang.ada Date: 1996-10-15T00:00:00+00:00 List-Id: Marin said " > In most of our work (control systems) it would be far more useful > for math over/underflows to saturate and continue on, rather than > raise an exception and halt processing. Ada never defined any > numeric types with this sort of behavior - and I find it difficult > to believe that many others in similar embedded applications > wouldn't also desire this behavior from some predefined floating, > fixed, and integer types. Of course, the language allows us to > define our own types and (if there's proper hardware and compiler > support for dealing with it) efficient "home-brew" solutions can > be built. Still, it would have seemed appropriate for the language > designers to have built some direct support for a very common > embedded need." Well there is always a certain kind of viewpoint that wants more, more, more when it comes to features in a language, but I think that saturating types would be overkill in terms of predefined integral types. Adding new classes of integral types adds a lot of stuff to the language, just look at all the stuff for supporting modular types. I think a much more reasonable approach for saturating operators is to define the necessary operators. If you need some very clever efficient code for these operators, then either use inlined machine code, or persuade your vendor to implement these as efficient intrinsics, that is always allowed.