Inconsistent use of 'Overflow' error.

A%=65536*32768-1 causes the variable A% to hold the value 2147483647, which is the correct value. Immediately after this assignment, A%=A%+1 (or even PRINT A%+1) causes an overflow, but not an overflow error. B%=65536*32768 causes an overflow error.

This is not inconsistent. 65536*32768 is a floating point value that is outside of the integer range, which causes an overflow when assigning to an integer variable. On the other hand, A%+1 is still an integer, albeit an overflowed one. Integer overflow causes no errors (since it is defined in modular arithmetic), but floating point assigned to an integer will. This is the only instance of an overflow error I am aware of.

variable=expression+1 causes an error. variable=expression:variable=variable+1 does not cause an error. If you cannot point to some SmileBasic documentation that clearly indicates why this should be so, then you and I should just stop talking to each other about bugs, because we are talking different languages.

I would say the inconsistency comes from the auto-promotion of constant expressions in the first place. If you forced a promotion by doing A%=A%+1.0, then you would get an overflow error. What I'm saying is that this is not an inconsistency on the part of the overflow error itself, but on the part of integers being promoted to floats in constant expressions.

And can you point to some SmileBasic documentation that clearly indicates what you just wrote?

No. But undocumented behavior is not the same as inconsistent behavior. The manual doesn't say anything that directly opposes this behavior, so it's not inconsistent. Besides, would you rather that A=65536*32768 produces a negative integer that gets assigned to a float? Sure, they could write a complete specification of how every single aspect of the language operates like the C standard, but that's complete overkill. If we wrote such a document ourselves, could this behavior still be considered inconsistent?

It's not undocumented. The built-in SmileBasic documentation includes the line: 9: Overflow (the calculation result exceeded the allowed range) To see it, type 'ERR', then tap the 'help' button, and go to page 2/20. For integer calculations, the allowed range is -2147483648 to 2147483647. Where the operands are all integers (and at least one of them is not a constant, avoiding the issue of "Operators perform differently depending on whether they are in a 'constant-folded' expression or not." http://smilebasicsource.com/forum?ftid=106 ), and the result goes to an integer variable, 2147483647+1 is a calculation whose result exceeds the allowed range, and it is a calculation that does not cause an Overflow error. The Overflow error occurs when some calculations exceed the allowed range, and the Overflow error does not occur when other calculations exceed the allowed range. This is inconsistent. As I have said in other threads, I do not feel comfortable making this personal. My own expectations and preferences are not the issue. Please stick to the issues.

I don't mean to make it personal. But thanks for clarifying what you meant. That is certainly some misleading documentation, since in fact it is never a calculation that produces an overflow error, but rather a conversion from float to integer. As far as lack of overflow errors in calculations is concerned, I get the feeling it's an instance of "it's not a bug, it's a feature" because of how annoying overflow errors were in PTC. There are many times where you would not want integer operations to generate overflow errors, for example when dealing with MAINCNT.

Gaar. Another instance: ... OR 0 doesn't change the value, right?

?POW(2,30),POW(2,30) OR 0
1073741824  1073741824
?POW(2,31),POW(2,31) OR 0
2147483648  2147483647

Any floating-point value greater than &H7FFFFFFF, when put in a context where an integer type is required, is silently changed to &H7FFFFFFF (even inf). Similarly, any number less than the biggest negative number is silently changed to the biggest negative number. nan becomes zero.

Of course this happens; OR is bitwise and only works on integers. inf and nan only exist in floating point numbers, so they need to be converted. At least it doesn't cause an error. There are way too many bug reports about the behavior of integers and floats; I'm moving this to programming questions.

Of course this happens; OR is bitwise and only works on integers.

And 2147483648 is an integer.

Of course this happens; OR is bitwise and only works on integers.

And 2147483648 is an integer.

That number does not fit into a 32 bit signed integer though. The maximum value is 2147483647.

Of course this happens; OR is bitwise and only works on integers.

And 2147483648 is an integer.

That number does not fit into a 32 bit signed integer though. The maximum value is 2147483647.

Exactly. OR only 'works' on the integer data type, but it 'works' with both numeric types.

Of course this happens; OR is bitwise and only works on integers.

And 2147483648 is an integer.

That number does not fit into a 32 bit signed integer though. The maximum value is 2147483647.

Exactly. OR only 'works' on the integer data type, but it 'works' with both numeric types.

It just converts numbers to integers before calculating the result.

It just converts numbers to integers before calculating the result.

Yes, and '1+1=10' is 'just' a sequence of symbols. And it is 'just' wrong, without extra context that is not always immediately apparent, and which should be avoided whenever not necessary or serves some useful purpose.

It just converts numbers to integers before calculating the result.

Yes, and '1+1=10' is 'just' a sequence of symbols. And it is 'just' wrong, without extra context that is not always immediately apparent, and which should be avoided whenever not necessary or serves some useful purpose.

And what do YOU think it should do?

And what do YOU think it should do?

I think the OR operator should implement the bitwise OR operation. No more, no less.

And what do YOU think it should do?

I think the OR operator should implement the bitwise OR operation. No more, no less.

That's what it does lol

I think the OR operator should implement the bitwise OR operation. No more, no less.

That's what it does lol

You yourself said it does not:

It ... converts numbers to integers before calculating the result.

Bitwise OR only works on integers.