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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fee8802cc3d8334d X-Google-Attributes: gid103376,public X-Google-Thread: 10a146,fee8802cc3d8334d X-Google-Attributes: gid10a146,public From: Marin David Condic Subject: Re: Ada and Java. different behaviour. casting long to int problem. Date: 1999/06/24 Message-ID: <377245BC.77B5A8A1@pwfl.com>#1/1 X-Deja-AN: 493390990 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <7jt2c0$vrb@drn.newsguy.com> <7k57vb$1ipf@drn.newsguy.com> <3766650F.705125B7@pwfl.com> <7k64t7$igo$1@its.hooked.net> <7k689a$ci2@drn.newsguy.com> <3766C842.E1EAB60A@pwfl.com> <7kp3f2$m9i$1@nnrp1.deja.com> <3770F79C.42132886@pwfl.com> <930160826.778.37@news.remarQ.com> <37873d89.955250958@news.bctel.ca> <3771417A.1541648A@pwfl.com> Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada,comp.lang.java.programmer Date: 1999-06-24T00:00:00+00:00 List-Id: Keith Thompson wrote: > Out of curiosity, would it generally be more useful for saturation to > be "sticky", like IEEE infinity? > I don't know about "generally" but I can speak for the areas where I'd like to have it :-) > For example, with non-sticky saturation, you might get something like > this: > > X : Integer := Integer'Last; > ... > X := X * 10; -- saturation, X = Integer'Last > X := X / 10; -- X = Integer'Last / 10 > > On the other hand, an infinite value in IEEE floating point is not > just a large number; infinity / 10 = infinity. > By which you mean that once I've run over the edge, there is no coming back? I think this would not be useful in a control application. Look at it this way: You are commanding a valve to move somewhere between full open and slammed shut. Assume that this is represented by an angle of 0..90 degrees. (The control laws will operate on a float or fixed point number, then when they decide where to command the valve, they give me the number and I translate it into a voltage (integer - d/a converter) that commands the actuator.) If the control laws software gets nutso and decides to command the valve to 105 degrees, I want the number to crop off at 90 degrees and stay there until the software regains its senses and perhaps starts commanding in the other direction. Usually this sort of clear-cut case is handled by explicit range checks within the system software, but the same sort of thing occurs for all sorts of intermediate calculations. In general, it is believed that if the control laws calculations saturate, we'll generally be better off with where it commands things. Definitely, wraparound is bad because it forces you to go from one extreme to the completely opposite extreme and that is stressful on physical hardware. You could imagine how this would also be practical for, say, graphics applications where you are computing X/Y coordinates or RGB colors. If you run off the edge of the window in your computation, then stay at the max value until the computation comes back within view. Likewise for colors - green all the way on + 1 shouldn't be green off. And eventually the adjustment would come back within range. > I suspect the answer depends on the application, and on what kind of > further calculations you want to do on saturated results. Making > saturation sticky would require reserving certain bit patterns in an > integer type, which would cause some run-time overhead on all > operations on that type. It would also make conversions between a > saturating type and an equivalent non-saturating type a little tricky. > As always, the answer is "It Depends" ;-) Sticking the value at +/- infinity until (presumably?) the object is totally reassigned might be a useful thing in some spots. Offhand, I can't think of any, but I'm sure there are computations which are better off "latched" once they go overboard. MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/