qbasic vs powerbasic

[Michael Mattias]

>if you are going to break the rules (which QB does not follow.)

???

The Microsoft BASIC IS following the rules... that is, its own documented behavior.

If you perform an operation which results in an overflow, it sets error code 6.

The PowerBASIC code is following its own documented behavior: If you perform an operation resulting in an overflow, you get pot luck without warning or the ability to test for that overflow.

In this case it's not about OBEYING the rules, it's about the rules themselves.

LOCAL x AS INTEGER
[/code]

This text saved it and I guess my absolute newness to powerbasic was my hurdle too high.
I wrote dim x as integer (or whatever variable) and that was seemingly it.
Thanks a lot

I know why the qbasic program is crashing, but the powerbasic program returns values it shouldn't well before the overflow error would occur. Very generally, the program has 3 variables, x, y and z and I mutiply x and y and mod z, I get one answer with qbasic, the correct one, and after even the first loop, powerbasic gives me the wrong result and it is a negative integer. I have the variables set as integer in both qbasic and powerbasic and the loop is identical. I reset the parameters to have a max value within the constraints of integer and now qbasic has no error and powerbasic still returns the wrong answer.

[Cliff Nichols]

Since I have been working on some error handling lately. (See "RunTime Debug and Error Handling Part III - Find that elusive bug")

I will bet your problem will show up as 1 of the values that PB rolls over ("Like an odometer") to protect you, vs a value you can not be protected from (aka:

• multiplication (*), division (/)
• division (\)

the 2 are NOT the same.... (hint)

[Guy Dombrowski]

I have yet to find a single instance where PB/CC math will fail.
If you have an overflow it means that your data type are not corrects.
Do you have #DEBUG ERROR ON ?

[Barry Erick]

Like MCM states., you need to know your data types before you can assume all is correct in your code. PB is correct in what you are seeing. You can try a different data type than integer if you are going to break the rules (which QB does not follow.)

[Michael Mattias]

On overflow (when X > 32767) no values can be trusted or believed.

Absent overflow checking, you are responsible for keeping your operands in the range of your selected data type.


MCM

[Mike Doty]

Infinite loop with PowerBASIC, overflow with QB

#COMPILE EXE
#DIM ALL
REM INTEGER range -32,768 to +32,767
FUNCTION PBMAIN () AS LONG
 2#+Ê;nbsp;LOCAL x AS INTEGER
  LOCAL Highest AS INTEGER
  Highest = 32767          'force overflow on the last NEXT statement
  FOR x = 1 TO Highest
  NEXT
  ? "The  value of x" + STR$(x)
END FUNCTION

Additional note added 7/10/09 7:43 AM:
PowerBASIC optimizes for performance so you must do range checking
so when the last "next statement" is executed it does not exceed the maximum for the data type.

7/10/09 7:43 AM

[Mike Doty]

Notice how this exits the loop because of the negative value.

#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
  LOCAL x AS INTEGER
  LOCAL Highest AS INTEGER
  Highest = 40000          'force overflow
  ? "Highest =" + STR$(Highest)
  FOR x = 1 TO Highest
    ? STR$(x)
  NEXT
  ? "You are here and x is" + STR$(x)
  SLEEP 2000
END FUNCTION

[Scott Slater]

It would help if you had some kind of sample code to post. Even if you can duplicate the situation with a similar code snippet. Otherwise it's very hard to understand what is happening.

I'm using the same program, with only a couple of syntax changes for q and powerbasic. Qbasic has an overflow error but returns all numerical values accurately. Powerbasic has no overflow errors but returns negative integer values where there shouldn't be any. I can't show you the code I'm afraid because it is worth something I think. I'd just like an idea as to why powerbasic might be failing with looping multiplication and division when qbasic succeeds.
First post, please be kind.
Michael.