There's not much problem IMO.
Subtract has a built in limiter which, when you subtract a number which would push it under 0, it will set to 0.
Trigger("Player 1"){
Conditions:
Always();
Actions:
Set Deaths("Current Player", "Goliath Turret", Set To, 5);
Set Deaths("Current Player", "Goliath Turret", Subtract, -3);
}
This is 0x00000005 - 0xFFFFFFFD = 0
Now try (-1) - (-100) = 99.
This is 0xFFFFFFFF - 0xFFFFFF9C = 0x00000063 = 99
You can't write outside the 4 bytes allocated to the data, so 0xFFFFFFFF + 1 = 0, not 0x01 00 00 00 00. I agree with nude that there are no overflows. Any "overflow" is blocked somehow, but you can always loop back.
In conditions, -1 > 1.
"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"
Probably I've mixed up the term "overflow" meaning.
What I call overflow is 0xFFFFFFFF + 1 = 0.
When I say there is no overflow it is 0xFFFFFFFF + 1 = 0xFFFFFFFF.
Some.
Then yes, I agree. There is no overflow on subtraction. There is overflow on addition.
"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"
The more I think about it the more I come to the conclusion scwizard is right.
In my opinion,
we should state DCs are unsigned
except for the addition operation, which yields overflows.
So technically one could implement signed DCs using only addition and negative integers encoding with higher integers, but on the triggers level they are still handled as unsigned.
Some.
I wouldn't really call it an overflow, I usually think of an overflow as when the modification happens further in memory than the variable itself, but this is contained inside the variable.
None.
In computer security and programming, a buffer overflow, or buffer overrun, is an anomaly where a process stores data in a buffer outside the memory the programmer set aside for it. The extra data overwrites adjacent memory, which may contain other data, including program variables and program flow control data
The term arithmetic overflow or simply overflow has the following meanings.
1. In a computer, the condition that occurs when a calculation produces a result that is greater in magnitude than that which a given register or storage location can store or represent.
2. In a computer, the amount by which a calculated value is greater than that which a given register or storage location can store or represent. Note that the overflow may be placed at another location.
A buffer overflow writes, an arithmetic overflow doesn't necessarily, but that's all semantics.
It's easier to say conditions are unsigned, and subtraction is unsigned and won't overflow, whereas addition is signed and overflow is possible.
"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
It's easier to say conditions are unsigned, and subtraction is unsigned and won't overflow, whereas addition is signed and overflow is possible.
According to Heinermann, whom I regard as the only expert on that matter here, said that actions (this includes additions and subtractions) are signed.
So I'd say conditions are unsigned, and subtraction and addition are signed. Subtractions won't overflow, but additions can.
I guess there's no difference between signed and unsigned when it won't overflow.
12 - -20 = 0 (overflow required for real answer)
-12 - -20 = 8 (no overflow needed)
"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"
When using subtract it is signed because it will not let the result be < 0. If the result is not < 0, it wont matter (and why would you ever need to subtract a negative?). Everything else is irrelevant or unsigned... Set To being signed or unsigned is a joke because there is no arithmetic involved, and Add doesn't matter because signed/unsigned are treated the same and there are no special cases (like Subtract having no results < 0). If the conditions read them as unsigned, then by all means just call them unsigned. ;o
TinyMap2 - Latest in map compression! ( 7/09/14 - New build! )
EUD Action Enabler - Lightweight EUD/EPD support! (ChaosLauncher/MPQDraft support!)
EUDDB -
topic - Help out by adding your EUDs! Or Submit reference files in the References tab!
MapSketch - New image->map generator!
EUDTrig -
topic - Quickly and easily convert offsets to EUDs! (extended players supported)
SC2 Map Texture Mask Importer/Exporter - Edit texture placement in an image editor!
This page has been viewed [img]http://farty1billion.dyndns.org/Clicky.php?img.gif[/img] times!
Nude, what do you exactly mean when you say subtraction and addition are signed?
Some.
When using subtract it is signed because it will not let the result be < 0. If the result is not < 0, it wont matter (and why would you ever need to subtract a negative?).
Nah. I did some more testing and subtraction works like this:
unsigned int death_sub(unsigned int ls, unsigned int rs) {
if(rs >= ls) return 0;
else return ls - rs;
}
Unless you can think of some sort of C code with signed numbers that displays behavior equivalent to how death counts behave.
If the numbers were signed and it checked to see if the result was less than 0, it would behave differently. For instance 0xFFFFFFFD - 0x00000001 would = 0 (it equals 0xFFFFFFFE), and 0x00000001 - 0xFFFFFFFD would = 4 (it equals 0).
None.
Um, 0xFFFFFFFD - 0x00000001 = 0xFFFFFFFC aka -3 - 1 = -4
0x00000001 - 0xFFFFFFFD = 0x00000000 aka 1 - -3 = 0.
The result can be less than 0, but it won't go from 0x00000000 to 0xFFFFFFFF, which would mean an overflow occurred. If you consider subtraction as always unsigned, then it works out perfectly.
@ Wormer, nude is saying Heinermann says that subtraction is signed.
"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"
Nude, what do you exactly mean when you say subtraction and addition are signed?
@ Wormer, nude is saying Heinermann says that subtraction is signed.
Yes, I want to know how he understands it.
Some.
