[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Saturated Arithmetic (Forked from Swift: overflow raises an error)
- From: Tim Hill <drtimhill@...>
- Date: Thu, 12 Jun 2014 20:38:55 -0700
On Jun 12, 2014, at 8:22 PM, Roberto Waltman <firstname.lastname@example.org> wrote:
> On 06/12/2014 19:48, Tim Hill wrote:
>> It’s less “ints behave like C” than “ints follow the behavior of the underlying hardware”, which these days almost always means 2’s complement with overflow. I’m really not too sure clamping is better than overflow .. at least with overflow when it happens it’s (usually) pretty obvious; clamping has greater potential to go undetected.
> That is called "Saturated Arithmetic" and is common in DSP processors. In many situations it is the preferred behavior.
> Let's say you are implementing a PID loop to control the speed of an electric motor. Adding a small positive correction value to a large positive previous value (that will overflow) will result in:
> Saturated Arith will give you still a large positive value (with the wrong speed.)
> 2's overflow will give you a large negative value, reversing the motor from (close to) full forward speed to (close to) full reverse.
> The first error is much more tolerable than the second.
> See: http://en.wikipedia.org/wiki/Saturation_arithmetic
> Roberto Waltman
Of course and understood (done significant DSP work some years back). I wasn’t saying that overflow was a good thing, but as I noted saturation/clamped arithmetic is not a panacea either.