Wow guys... don't overcomplicate it.
unsigned and signed does NOT change how the values are stored or read, but how they are interpreted. That's simply a definition that tells the computer how to convert the bits and bytes it reads into a decimal number.

I know that, but the issue is that a lot of math operations, such as At Least or At Most, like SC has, will have issues with using an unsigned integer instead, since while it's technically negative, the actual function will return as if it is positive.

As far as I know At Least is signed.

So how does that work? It just considers anything under 2147483648 positive and anything over is negative?

Anything with Bit 31 set is negative. Let me actually test my claim that DCs are signed...

Ok, so apparently they are unsigned (unless my testing triggers were flawed)... Luckily, though, you can do like At Least (normal, negative value) and as long as the value can't be >= 0 it will be accurate... if the value can be positive, you need more conditions.

Post has been edited 2 time(s), last time on Feb 18 2009, 4:04 am by FaRTy1billion.

Ah, I knew they were unsigned, hence my argument, I just didn't think about using a negative number in the at least or whatever part, that kinda clears things up, although there are still a few bugs with that.

You can still subtract past 0, though. As I said, it is exactly the same.

Yeah, I knew you could, I just thought that errors with the number technically being positive, but not negative, might cause issues with some math operations using At least or At most.

So then, let me get this straight:

If you "subtract" a number, and it's less than 0, it will be set to 0.

If you "add" a number which has the 31st bit set (negative), it will subtract the two like this:
_1111 1111 1111 1111 1111 1111 1111 1111 = -1
+0000 0110 1011 1011 0000 0011 0101 0001 = 1622868817
=0000 0110 1011 1011 0000 0011 0101 0000 = 1622868816
The 1 on bit 32 drops out because there is no bit 32.

When you use the "at least" or "at most" argument, it does not check for 31st bit, and means that any negative number will be considered higher than a positive number (see above -1 in binary > 1622868817 in binary). Due to the way the negatives work, -1 in binary > -18564842 in binary, so if the number is only negative or only positive, the two arguments work fine.

Did I miss anything?

I am so confused. I think TZ's idea was much more simple.

I think so, that's what I was discussing with Farty, so if you are needing to use negatives this way, you can't use those conditions as well.