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,fee8802cc3d8334d X-Google-Attributes: gid103376,public X-Google-Thread: 10a146,fee8802cc3d8334d X-Google-Attributes: gid10a146,public From: "Mike Silva" Subject: Re: Ada and Java. different behaviour. casting long to int problem. Date: 1999/06/24 Message-ID: <7kthut$42u$1@its.hooked.net>#1/1 X-Deja-AN: 493400091 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> Organization: Whole Earth Networks News X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Newsgroups: comp.lang.ada,comp.lang.java.programmer Date: 1999-06-24T00:00:00+00:00 List-Id: Keith Thompson wrote in message ... > >Out of curiosity, would it generally be more useful for saturation to >be "sticky", like IEEE infinity? > >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. In the situations I can imagine using a saturating variable (control loops) this would *not* be good! Suppose the value represents e.g. a control surface output -- it's legitimate to have it "pegged" at full travel for a while in response to a very large error (in the control loop sense) signal, but when the error comes down and even reverses sign, you sure don't want the control surface to stay pegged! PID controllers can have a similar situation called integral windup, where the internal integeral keeps building up while the control output is pegged, and then when the error begins to reduce and finally reverses sign that large built-up integral has to be "emptied" by the opposite error before the control output responds correctly -- in the meantime the output is pegged in the wrong direction. Modern PID controllers specifically avoid this behavior, similar to the way a non-sticky saturated variable would avoid it. Mike