Inconsistent use of 'Overflow' error.

You appear to be conflating 'integer' with 'integer data type'. A=2147483648 stores the integer value, 2147483648, in the variable A. For any integer value A, the expression (A bitwise-OR 0) is identically equal to A. In SmileBasic, ?(A OR 0)==A returns 0, 'false'.

but 2147483648 cannot be stored as a (32 bit) integer in SmileBASIC, since it uses more than 32 bits. So it is stored as a floating point number, which doesn't support bitwise operations. This is the same as basically any other language.

but 2147483648 cannot be stored as a (32 bit) integer in SmileBASIC, since it uses more than 32 bits. So it is stored as a floating point number, which doesn't support bitwise operations. This is the same as basically any other language.

The representation is not the thing represented. 2147483648 is 2147483648, whether or not it fits on an old-style 8-digit calculator display, 2147483648 is 2147483648 whether or not it fits in a 32-bit signed integer data type, 2147483648 is 2147483648 whether or not it is represented, in one instance, in IEEE floating-point standard, 2147483648 is 2147483648 whether or not it is represented, in one instance, in a 64-bit integer data type, and 2147483648 is an integer.

but 2147483648 cannot be stored as a (32 bit) integer in SmileBASIC, since it uses more than 32 bits. So it is stored as a floating point number, which doesn't support bitwise operations. This is the same as basically any other language.

The representation is not the thing represented. 2147483648 is 2147483648, whether or not it fits on an old-style 8-digit calculator display, 2147483648 is 2147483648 whether or not it fits in a 32-bit signed integer data type, 2147483648 is 2147483648 whether or not it is represented, in one instance, in IEEE floating-point standard, 2147483648 is 2147483648 whether or not it is represented, in one instance, in a 64-bit integer data type, and 2147483648 is an integer.

But it doesn't change the fact that you're wrong.

But it doesn't change the fact that you're wrong.

Illuminating. Could you be more specific? 1: Wrong in claiming that the bitwise-OR operator, when given the pair of operands, the value 2147483648 and the value 0, yields 2147483648? 2: Wrong in claiming that the SmileBasic OR operator, when given the pair of operands, the value 2147483648 and the value 0, (EDIT: sometimes) yields 2147483647? 3: Wrong in claiming that the SmileBasic OR operator is different from the bitwise-OR operator? (EDIT: I mean to say, Wrong in claiming that the SmileBasic OR operator is a buggy implementation of the bitwise-OR operator?)

3 Doing a bitwise OR on a floating point number would produce a result that is completely wrong. The number must be converted to a fixed point type first, and since SB uses 32 bit integers, that's what they had to do, just like any other language.

So you're okay with 1 and 2?

2147483648 OR 0 is 2147483648 ONLY IF you are using integers larger than 32 bit. ?2147483648 OR 0 triggers an overflow error during compilation; before the program runs. This is because expressions containing constants are evaluated before the program starts, to increase speed. A#=2147483648:?A# OR 0 converts A# into the nearest 32 bit integer, which is 2147483647 I will admit that this is a bit strange. I just realized that this happens because of constant expressions being compiled. This could be considered a bug with the precompiler, but luckily it shouldn't cause any problems, because you'd never need to use an expression like 2147483648 OR 0

See, you write as if 'being floating-point' and 'having bits' are properties of numbers. As long as you do, you are not making the critical distinction between the representation and the thing represented. EDIT: I should expand on this point, I think. There is a thing called a 'category error', which makes a sentence or phrase, not only not right, but not even wrong. "The colour of my house is white" is correct. "The colour of my house is orange" is wrong. "The colour of my house is 20 feet" is a category error. "2147483648 is an integer" is right. "2147483648 is odd" is wrong. "2147483648 is a floating-point number" is a category error.

I don't even understand the point of this argument anymore, so I'm going to politely defuse it. In SmileBASIC, bitwise OR performs a coercion on both values if they aren't integers. Complaining about this and suggesting it shouldn't just isn't helpful. This is the way it is, and you can't change that. This could be C where you can OR anything you want, but it's not, oh well. 2147483648 might be an integer in reality, but in SB it's not. Trying to put the behavior of SB in an environment and ruleset it doesn't really obey is just ridiculous. You're both making decent points, but you're not going anywhere. This isn't changing anything or isn't about any real issue anymore. Please spare yourselves and the rest of site activity.

Well, at least you politely called me ridiculous. Way to defuse.

I was calling the situation ridiculous. but sorry I said anything anyway, this isn't my place to be

I apologize, I wrote in haste - you did not call me ridiculous, and it was unfair of me to say that you did. But, if SB behaviour is only evaluated in the environment and ruleset it really obeys, then tautologically it has no bugs, and it boils down to the mere existence of a 'bug report forum' being ridiculous. As to my tenaciousness on this subject: Consider the pair of statements: - The SmileBasic OR operator does nothing more than the bitwise OR operation - The SmileBasic OR operator sometimes changes the values of the operands given to it, then performs the bitwise OR operation on the modified values. Or, the pair of statements: - There is a calculating machine which performs calculations, not on the numbers given to it (EDIT: for as nearly as those numbers can be represented in the machine), but sometimes on different numbers. - There is not a grave flaw in that calculating machine, in this respect. On the surface, for either pair, it appears stupid to put lots of conviction behind both statements in the pair. It is not my position that 12Me21 is stupid. So, it is unsettling to see this. I want to help 12 with the deeper issues, from which such surface issues stem. And, things like "The representation is not the thing represented", "The data type is not indivisibly attached to the data", these can be deep issues, that take effort to straighten out. Once they are straight, though, this can be really quite valuable, so some effort is worth it.

Sorry about all this. I've been moving threads inconsistently while I'm trying to decide what belongs in Bug Reports and what doesn't. These threads have been hard to categorize since there is disagreement about whether this is a bug or not. I think I'll just leave everything that isn't just an obvious mistake in someone's program from now on, just in case.