|
imnota10Join Date: 2010-12-25
Post Count: 2594 |
"It's not unexpected, people who don't understand how integers were are just oblivious to it. In fact, if Lua didn't allow you to overflow then it would make less sense.
0111 + 0001 should not be 1000? It's just logic, read up how signed integers work and you'll realize why it's not a bug."
Are you not a programmer, or are you just trying to be right? Let me give another example.
int main() {
long signed int x;
cin (input 2 ">" brackets here) x;
cout (input 2 "<" brackets here) x;
return 0;
}
In this example, you can get a positive number, and are in fact, most likely expecting it. The maker of this program is NOT expecting them to enter a value such as 99999999999999999999999999999999999999999999999999999999999 and getting a value that is not that. Hence forth, they did not program a way to fix this, and henceforth it is a bug. It's not about how the actual circuitry works, it's what the intent of the program is. Saying: "A number reaching that value becoming negative is common sense, hence forth it is not a bug" is a logical flaw. In C++, a conversion from say a double to an int is a valid operation, but there are features in the language that would make this operation illegal because it MAY NOT BE the intention. Also, if you wish to do something like... Make a pointer to a const variable, you have to declare the pointer as a pointer to const, because otherwise you would be allowed to write to a const object, which would ACTUALLY change a temporary object's value, not the value of the constant variable that the pointer points to, which once again, is NOT what the programmer intended. Is there a reason for this? Yes. Does that change the fact that it's not what is wanted? No. The actual physical mechanics is not what matters. It does not matter what current is running through which circuit and what value you get from this. The INTENTION of the code is what matters when debugging, not determining if the value you get makes sense, which of course it will. Anything that happens, happens for a reason. That DOESN'T make it any less of a bug. |
|
cntkillmeJoin Date: 2008-04-07
Post Count: 49450 |
Oh I read your #1 wrong.
'Okay, very well, it's a float. Doesn't change the fact that they had to code it in to check if the value is above the maximum excepted value. I'm not going to argue about grouping UI sections and functionality. The problem is stated, and a solution is known. There's no reason for a fix.'
Floats really don't have a maximum: http://en.wikipedia.org/wiki/Floating_point
'What are you talking about? Was this sarcasm to try to claim that languages SHOULD manage this? In which case you're wrong. It's in no way a languages job to prevent the conversion from positive to negative. A good language wouldn't do that honestly. A good language will do only what is HAS to do, and leaves the programmer to decide what behavior they wish to change. '
I said they shouldn't, yet your original post says that it becoming negative is a "bug".
'That's not "adding 1" though. That's a complete misrepresentation of what is happening.
I'm not explaining this well at all. You're right though, but that's not the point I've been trying to make. '
For the case of positive going to negative, it IS adding 1. Our representation is just using the MSB to destroy our extra bit for the sign. Think about it, if you have 4 digits to work with:
9999 + 0001
The 4 digits you can use will become 0000 after that.
'The EXPECTED result it to achieve a constantly increasing value. When this inevitably DOES NOT HAPPEN, it is referred to as a bug.'
You expect it because you aren't taking into consideration of computer limitations.
'No, it's not a "large" number. That's a completely different thing in programming that involves increasing the amount of space being occupied in memory by an object with that specified base type.'
Yes, it is a large number. If you did not represent the MSB as the sign, you have a whole extra bit of storage (hence, unsigned). Thus you can go up to 2 ^ bits - 1 instead of (2 ^ (bits - 1) - 1) (or (((2 ^ bits) / 2) - 1)).
I'll try to say this because I don't know if I was clear enough:
HUMANs represent negative numbers on processors in 2's compliment (for the most part, of course this may change in the future or whatever).
2's compliment uses the most significant bit as the sign bit, giving you 1 less bit to work with for storage.
For example, let's say my number is 4 bits large. No matter how I choose to represent it (signed or unsigned), the computer holds it as unsigned (the computer doesn't know what negative numbers are, we give it meaning).
So my number 15 (I only have 4 bits here):
1111
Will be 15 when not caring about the sign bit (the left-most in this case, the most significant).
However, if I choose to represent the MSB as the "sign" bit, then our number would actually be (in 2's compliment) -1.
This is not a bug, it's just how they work. |
|
cntkillmeJoin Date: 2008-04-07
Post Count: 49450 |
'Are you not a programmer, or are you just trying to be right? Let me give another example.'
Read my last post, maybe you'll understand how we represent negative numbers and maybe you'll understand what I'm trying to say.
And for your example, if we compare it to having unlimited space to store our numbers then sure, it's a bug. But we don't!
If they enter a large number like that and get a different number then it's the computers fault, not the programmers fault. Let the computer apologize for not having an unlimited amount of bits to store your gigantic number in.
You might consider it a bug, but people who understand what they are doing know it's just how computers work. They don't have infinite storage to hold your super large number.
You know, I'm going about this the wrong way.
Your lens says "I'm getting something different than what I expect, is a bug"
Which makes sense, but on the hardware, it's a LIMITATION, not a BUG. |
|
|
It's not a bug. It does this for any programming languages that uses signed (or even unsigned) integers, bytes, longs, shorts, etc.
This is the reason why why the first Zelda game's max rupee count was 255, because that's the max value of an unsigned byte/char.
"a integer's maximum value it totally dependent on the machines architecture. However, you're right if you're assuming the hardware that most PC's have, as far as I'm aware."
This is untrue. A signed integer is completely defined as 2^(32-1) - 1 and unsigned int32 is (2^32) - 1. This has nothing to do with PC architecture (I think you meant processor). If you use an int on a 32 bit computer, it's 32 bit. If you use int on a 64 bit computer, an int is still 32 bit. There are special ints but that depends on the compiler, for example, Visual C++, but not processor architecture.
"This is a common bug in coding, and can easily be fixed on Roblox's part."
If it's so easy, tell us how to fix it, with code.
|
|
imnota10Join Date: 2010-12-25
Post Count: 2594 |
"Floats really don't have a maximum: http://en.wikipedia.org/wiki/Floating_point"
Did you even read that? Or even better, run some code to test that?
I ran this float value in my code::blocks compiler: 9999999999999999999999999999999999999999.9999999999999999999999999999999999999999
And got the value: "Inf"
It just outright could not print that value.
The fact of the matter is, it DOES have a limit. Everything has a limit. If you think something doesn't have a limit, you're just wrong.
I said they shouldn't, yet your original post says that it becoming negative is a "bug".
Yes, because the intention was not for it to become negative. It is a bug.
"For the case of positive going to negative, it IS adding 1. Our representation is just using the MSB to destroy our extra bit for the sign. Think about it, if you have 4 digits to work with:
9999 + 0001
The 4 digits you can use will become 0000 after that."
But you're not "adding 1". adding one is a decimal system thing. At most you're shifting the 2nd left most bit to the left, and setting the rest to 0. You are NOT adding one, because that has no meaning in binary.
"You expect it because you aren't taking into consideration of computer limitations."
EXACTLY. that doesn't make it any less of a bug. The result is not expected, hence forth it is a bug.
"Yes, it is a large number. If you did not represent the MSB as the sign, you have a whole extra bit of storage (hence, unsigned). Thus you can go up to 2 ^ bits - 1 instead of (2 ^ (bits - 1) - 1) (or (((2 ^ bits) / 2) - 1))."
Nevermind, I mistakened the word "large" for "long". My bad.
"I'll try to say this because I don't know if I was clear enough:
HUMANs represent negative numbers on processors in 2's compliment (for the most part, of course this may change in the future or whatever).
2's compliment uses the most significant bit as the sign bit, giving you 1 less bit to work with for storage.
For example, let's say my number is 4 bits large. No matter how I choose to represent it (signed or unsigned), the computer holds it as unsigned (the computer doesn't know what negative numbers are, we give it meaning).
So my number 15 (I only have 4 bits here):
1111
Will be 15 when not caring about the sign bit (the left-most in this case, the most significant).
However, if I choose to represent the MSB as the "sign" bit, then our number would actually be (in 2's compliment) -1.
This is not a bug, it's just how they work."
Already explained why this doesn't matter. Read it. |
|
imnota10Join Date: 2010-12-25
Post Count: 2594 |
"You know, I'm going about this the wrong way.
Your lens says "I'm getting something different than what I expect, is a bug"
Which makes sense, but on the hardware, it's a LIMITATION, not a BUG."
This isn't about hardware, it's about software. |
|
cntkillmeJoin Date: 2008-04-07
Post Count: 49450 |
At this point you're not reading anything I'm saying. I just said they did have limits, which how I proved your 999... thing wrong. Now you're just saying what I'm saying.
At this point you're saying nothing. Limitation is not a bug, get over it. |
|
cntkillmeJoin Date: 2008-04-07
Post Count: 49450 |
Or I'm stupid and this whole thing is a stupid troll.
I'm done replying because everything you have tried to argue about was already proven wrong if it was incorrect. |
|
|
http://www.tutorialspoint.com/cplusplus/cpp_data_types.htm |
|
imnota10Join Date: 2010-12-25
Post Count: 2594 |
I don't know how to be any more clear than I am. I AM NOT TALKING ABOUT THE LIMITATIONS OF THE HARDWARE. The fact that a value of say 99999999999999999999 would become negative is NOT the bug, the bug is the fact that the program ALLOWS the conversion to occur in the code.
I'm trying to post a simple 7 line code that would fix this problem in C++, but Roblox is not allowing it.
|
|
cntkillmeJoin Date: 2008-04-07
Post Count: 49450 |
'... the bug is the fact that the program ALLOWS the conversion to occur in the code.'
It's more of an inconvenience than a bug. But suppose you were able to change how integers are handled, what would you rather have it do? |
|
AbsurdismJoin Date: 2013-07-18
Post Count: 2568 |
quote: I never said the assembly has anything to do with the size. My exact words were: "They'll probably even have entirely different forms of assembly language."
rofl this made my day |
|
|
http://stackoverflow.com/questions/10011372/c-underflow-and-overflow |
|
|
Scriptable
Learn Lua and gui and fix it yourself your place your problem |
|
|
If you can't post that code, use pastebin, or similar. |
|
imnota10Join Date: 2010-12-25
Post Count: 2594 |
http://pastebin.com/2KWKT9Rh
Dunno if the link will work, but that's the code. |
|
cntkillmeJoin Date: 2008-04-07
Post Count: 49450 |
-.- no, of course it wouldn't work.
It would be impossible for an (assumed 32-bit int, that is signed) to be above that. |
|
imnota10Join Date: 2010-12-25
Post Count: 2594 |
What wouldn't work? |
|
cntkillmeJoin Date: 2008-04-07
Post Count: 49450 |
Oh you put a "long", well that defeats the whole purpose since you're handling that 32 bit signed max in a 64 bit signed. |
|
imnota10Join Date: 2010-12-25
Post Count: 2594 |
No, once again, it depends on the system, but in most cases in C++ a long int is 4 bytes and a regular int is 2 bytes. |
|
imnota10Join Date: 2010-12-25
Post Count: 2594 |
Though I just realized that my code doesn't work, and that my compiler automatically sets X to the maximum value that a 4 byte integer can be, given a value far above it.
(Once again, because the people who made the compiler knew this is a common bug and put in handling that problem within the compiler itself) |
|
cntkillmeJoin Date: 2008-04-07
Post Count: 49450 |
It depends on the compiler, whatever:
Assume int is thirty-two bits and long is sixty-four for simplicity reasons.
You define a signed int, it would be impossible to check if it's greater than 2^31-1 because it would have overflowed and became negative.
If you check for that with a long, that defeats the purpose because it's not actually being limited by that number. |
|
imnota10Join Date: 2010-12-25
Post Count: 2594 |
Yes, that's true, but irrelevant when the real life scenario says that a long int is 4 bytes.
I think it's pretty safe to assume by now you don't do much coding, as you have a mind more set on hardware. To explain simply, the hardware sets the value to negative, but in programming, you DON'T want that, so you have to program it to bypass the hardware limitations. People do this in many different ways, such as the example I showed where they'll just set it to the maximum value. People will also put it into scientific notation so as to at least keep the general concept of how big the number is. I've never seen it, but I'm sure with some manipulation of strings you could keep the full precision of the number too by maybe using a vector of ints to store all the maximum values, and the one (most likely, but not always) none-max value, and using some max to add each number together based on where it is relative to each other (add the one's to each other, the ten's to each other, hundred's, thousand's, etc...) and eventually come out with a string that has full precision. But you couldn't use it in arithmetic operations, it would simply be for showing the size of it. |
|
imnota10Join Date: 2010-12-25
Post Count: 2594 |
*Math, not max. |
|