Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic <condicma@bogon.pwfl.com>]

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/