Announcement

Collapse
No announcement yet.

qbasic vs powerbasic

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • qbasic vs powerbasic

    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.

  • #2
    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.
    Scott Slater
    Summit Computer Networks, Inc.
    www.summitcn.com

    Comment


    • #3
      Notice how this exits the loop because of the negative value.
      Code:
      #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
      Last edited by Mike Doty; 9 Jul 2009, 05:46 PM. Reason: Might not have PBCC
      How long is an idea? Write it down.

      Comment


      • #4
        Infinite loop with PowerBASIC, overflow with QB
        Code:
        #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
        Last edited by Mike Doty; 10 Jul 2009, 08:45 AM. Reason: Did not post correctly, FOR statement was on same line as the line before it.
        How long is an idea? Write it down.

        Comment


        • #5
          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
          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            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.)
            Barry

            Comment


            • #7
              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 ?
              Old QB45 Programmer

              Comment


              • #8
                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)
                Engineer's Motto: If it aint broke take it apart and fix it

                "If at 1st you don't succeed... call it version 1.0"

                "Half of Programming is coding"....."The other 90% is DEBUGGING"

                "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    Originally posted by Mike Doty View Post
                    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

                    Comment


                    • #11
                      >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.
                      Michael Mattias
                      Tal Systems Inc. (retired)
                      Racine WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment

                      Working...
                      X