# Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

### Bug Reports / Binary operation thinks –2,147,483,648 is out of range for an integer

Message
Posted: 26th May 2013 05:30 Edited at: 28th May 2013 21:56
Edit 2
First I thought I made a mistake, then I found out that this is still an issue, the compiler should allow you to perform calculations such as –2,147,483,648 && 4.

Edit

, ignore this because I am counting from 1 instead of 0; counting from 0 to 31 is 32 bits. When I assigned bit number 33 thinking it was number 32, it caused an arithmetic overflow.

Quote: "(INTEGER Range –2,147,483,648 to 2,147,483,647)"

Quote: "Error: Must user integer data type for bitwise operations at {line number}"

This error handler is what is out of range; –2,147,483,648 is a valid integer; this is the round trip of the digital representation of the 32nd bit; however an error message indicates that this is not so.

It is a not a terminal compiler error, so the program runs; and the following calculation indicates that the actual code works:

This issue was raised by attempting to assign the 32nd flag of an integer. The DWord equivilent; 4294967296, is redundant because the calculation is cast to an integer.

Posted: 28th May 2013 00:35 Edited at: 28th May 2013 00:37
....

Apparently 2147483648 (2 ^ 31) is out of range as well

The literals only permit 31 bit operations... A work around is to trick the compiler into thinking the operands are valid by using a calculation instead of a literal:

Posted: 28th May 2013 02:06 Edited at: 28th May 2013 02:09
From the Help file [Edit or your first post ]:

Quote: "INTEGER Range : –2,147,483,648 to 2,147,483,647"

If I recall correctly, integers and dwords have the same range - they are merely presented differently. For example:

Notice in particular how the higher dword values correspond to the negative integers. Note also that the positive and negative integer ranges are asymmetric - they have to be because there are an even number of different possible values altogether and 0 occupies one of them.

In each case, i.e. dword and integer, there are 2^32, i.e. 4,294,967,296, different values. There is no mystery that I can see.

Your snippet doesn't compile for me.
Posted: 28th May 2013 21:36 Edited at: 28th May 2013 22:01
Yeah in theory that is mostly correct, but putting the digital sign aside, DBPRO even thinks -2147483648 is not a valid integer when compiling bitwise calculations. Same error message for the following 32bit boolean calculation:

-2147483648 && -2147483648 outputs 0 when run, but throws up the compiler error. I am not sure why it doesn't run for you

2147483647 && 2147483647 successfully compiles, but is not equal to 2^31.

Quote: "In each case, i.e. dword and integer, there are 2^32, i.e. 4,294,967,296, different values. There is no mystery that I can see."

2^32 is what I thought was valid before, but that is an invalid 32bit calculation; consider that 2^0 = 1, which is the first bit, and there are 32 numbers between 0 and 31. 32 is the 33rd number counting from zero.

In another expression, if (2^32) was valid for 32 bit boolean calculations; then so would (2^31) OR (2^32), which would add up to 6442450944, which is out of range for a DWord the same way (2^7) OR (2^8), inturn 128 || 256 adds up to 384 which is out of range for a byte. If DBPRO supported signed bytes(-128 to 127), 2^7 would be -128.

This all can be confirmed using the Matrix1 64 bit calculation below which successfully performs an OR operation on the 32nd and 33rd bits.

I am sure the compiler has it all wrong; all by one unit.

Posted: 29th May 2013 00:56 Edited at: 29th May 2013 01:55
I see what you mean now (I've only just seen your second edit to your first post).

However, your code doesn't compile and gives the error message:

Quote: "Must use integer data type for bitwise operations (etc)"

That's why it doesn't run for me. I'm surprised it compiles for you. Here's what I see in the editor:

Although I agree there's something wrong with the error message I have to say that bitwise operations on negative integers don't make make much sense to me (I realise you can do bitwise operations on any data type since, ultimately, they are all represented by bits - but it hardly makes for easily readable and understandable code to do this with negative integers, floats, etc). Unless, of course, you are simply trying to find out what the bits are, in which case there ought to be simpler ways of proceeding.

I'm also completely baffled by this statement:

Quote: "2147483647 && 2147483647 successfully compiles, but is not equal to 2^31."

It does compile as it should and also gives the correct result, i.e. 2147483647. Why should it equal 2^31?

I think the only error here is what you suggested originally, i.e. that the compiler thinks -2147483648 is out of range for literals when it's doing bitwise operations (probably because of a clumsy application of the defined range?). As you mentioned earlier, putting the values into a variable or calculation bypasses the issue and gives the correct result as in this code:

#### Attachments

Posted: 29th May 2013 02:29 Edited at: 29th May 2013 02:39
Quote: "I have to say that bitwise operations on negative integers don't make make much sense to me (I realise you can do bitwise operations on any data type since, ultimately, they are all represented by bits - but it hardly makes for easily readable and understandable code"

Definitely, You can use 4,294,967,296 DWord equivalent instead ; but DBP casts all bit-wise calculations to integers, so in the program it do the round trip which could not be compared if used in a DWord comparison. A situation could arise where 4,294,967,296 is compared to -2147483648 in a DWord or double integer comparison. Safer to stick to what is says on the tin.

Quote: "That's why it doesn't run for me. I'm surprised it compiles for you."

Ah, it might be the IDE; I use Indigo.

Quote: "Why should it equal 2^31"

For comparison. If I compare (2^31) and 2147483647, I get false. 2147483647 && 2147483647 is as true as 1234 && 1234, but these are not single bit predicates for a logical condition; they flag up more than one flag. For logical predicates, each check must represent one bit and only one bit in the range.

The integer difference between 2147483647 and 2147483648 is the complete opposite when you look at the numbers in binary form:

Quote: "
print bin\$( (2^31) ) = %10000000000000000000000000000000
print bin\$( (2^0) ) = %00000000000000000000000000000001

print bin\$( 2147483647 ) %0111111111111111111111111111111
print bin\$( 2147483648 ) %10000000000000000000000000000000
"

The IF branch in the following confirms.

My goal is to implement 32 customizable flags for one of my entity tools; simply because the 32 bit bit-wise operation is the fastest. Fortunately there is a work around, however that last flag is going to be a laggy one...

Posted: 29th May 2013 13:08
Quote: "Quote: "Why should it equal 2^31"

For comparison."

What do you mean?

For bitwise operations "x && x" should return x regardless of the value of x.

Quote: "If I compare (2^31) and 2147483647, I get false. 2147483647 && 2147483647 is as true as 1234 && 1234"

You're losing me now. It's obvious that you'll get false if you test two different things for equality.

As for the phrase "2147483647 && 2147483647 is as true as 1234 && 1234", what do you mean? They are both numerical expressions. What is your point exactly?

Quote: "A situation could arise where 4,294,967,296 is compared to -2147483648 in a DWord or double integer comparison."

You cannot represent 4,294,967,296 as a dword since it is 33 bits long, i.e. 4,294,967,296 = 2^32 = %1 0000 0000 0000 0000 0000 0000 0000 0000 (I've inserted spaces to aid readability). And why can't you compare 4294967296 and -2147483648 in a double integer comparison? I'm afraid you've lost me again.

Quote: "The integer difference between 2147483647 and 2147483648 is the complete opposite when you look at the numbers in binary form:"

Indeed. But we both know that already. What is your point exactly?

Aside: I don't think we're disagreeing on anything of substance here. My guess is that we're somehow at cross-purposes and should just accept the fact that you're original post was correct, i.e. that in one particular situation the compiler flags an error when it shouldn't.
Posted: 29th May 2013 13:37 Edited at: 29th May 2013 13:56
Quote: "I'm also completely baffled by this statement:

Quote: "2147483647 && 2147483647 successfully compiles, but is not equal to 2^31."

Why should it equal 2^31"

For comparison."

What do you mean?"

Don't worry Green Gandalf; we are on a different wavelength at the moment. You ask about why my statement implies that the value should be equal; but was written that state that is not equal, and that it should not be. The argument is about the compiler accepting the maximum, but not the minimum integer range in bitwise calculations.

I am talking about what I need, I'm not telling you how things work; I am answering the questions with answers about why I need this to work, not to teach you about what you already know.

Posted: 30th May 2013 13:52
Quote: "we are on a different wavelength at the moment."

Very true.
Posted: 4th Jul 2013 07:55
Quote: "Apparently 2147483648 (2 ^ 31) is out of range as well"

That's not the maximum number, just the maximum range. Don't forget 0. Just as 2^8 = 256 for a byte (which is 0-255), so is the integer:
maxInt = (2^31) - 1

Since a dword can use that extra 32nd sign bit for data, it's range is technically the same but its max value is twice as high.