less than zero value

[Simon]

if I carry out a calculation with an unsigned integer and the result is less than 0 will the result default at 0 ? I just want to make sure it does not do anything dunny like roll over and give me something wiered like a larger value than I started with.

[Kalvin]

if I carry out a calculation with an unsigned integer and the result is less than 0 will the result default at 0 ? I just want to make sure it does not do anything dunny like roll over and give me something wiered like a larger value than I started with.

Presumably you are referring to C? Yes, if the unsigned int overflows / underflows, you will get a large positive number, thus being a careful programmer you need to check that the input value is within the range producing valid results - not the output value as the damage has already be done. However, if you know that the result should be a quite small number compared to the maximum unsigned number, then you should be safe checking the output value.

You can try this assigning a small value to an unsigned integer and subtracting a larger value from it. Print the result and you will find out.

[StuUK]

You may well get wrap around behaviours which lead to non-zero values....

[Simon]

This is using GCC C on AVR, ok, maybe best I just use a signed number format just in case, it's not a time sensitive program so extra time spent dealing with a larger number format in 8 bit is not a problem.

[madires]

You could also check the values before doing the calculation:

Code: [Select]

/* the calculation is "a - b" */
if (b > a)        /* prevent underflow */
{
  a = 0;
}
else              /* no worries */
{
  a -= b;
}


[zapta]

This is using GCC C on AVR, ok, maybe best I just use a signed number format just in case, it's not a time sensitive program so extra time spent dealing with a larger number format in 8 bit is not a problem.

What do you want to happen, detect the underflow (overflow) and do something special? Just clip it to zero (255) and not let it underflow (overflow) ?

[Kalvin]

You may find this document interesting: "Branchfree Saturating Arithmetic"
http://locklessinc.com/articles/sat_arithmetic/

[Simon]

This is using GCC C on AVR, ok, maybe best I just use a signed number format just in case, it's not a time sensitive program so extra time spent dealing with a larger number format in 8 bit is not a problem.

What do you want to happen, detect the underflow (overflow) and do something special? Just clip it to zero (255) and not let it underflow (overflow) ?

Yes, or being that the range of "underflow" is known I can use a signed type

[thm_w]

Some TI DSPs have saturation option, safely avoids overflow issues while preserving speed.
But if you have the cpu cycles available I would check it in code. Then you have the ability to log or flag it for investigation.

[Brumby]

You could also check the values before doing the calculation:

I am of the school that checking for potentially problematic conditions is best done beforehand.  The values you will be working with will be certain and the tests unambiguous.

Trying to identify a problem afterwards means you may well have entered the twilight zone - an area of uncertainty that may vary between platforms.  Also, in an abnormal situation, it is rather unwise to depend on a specific response for guaranteed operation.  If different platforms give different responses, you are not going to have guaranteed operation.  It is much better to deal with potential problems than real ones.

Aside from this, there is also the issue of coding clarity and documentation.  Ii's a lot easier for you (or anybody) who comes along at a later date that looks at the code to read an explicit value check, rather than a verbose description of the 'default behaviour' you are relying on (assuming you would be so disciplined to do so).

In short, it is better programming practice to check your values before using them.

IMHO.

[Simon]

I will just use int_16, a negative value is not a problem as I am doing a subtraction that will produce a negative value so it makes sense to work with signed values rather than try to clip it. int_16 still gives me 32'000 numbers either way and my numbers are in the hundreds so plenty of headroom.