Announcement

Collapse
No announcement yet.

Variable Type

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

  • Variable Type

    Greetings!

    I'm looking at some hex from a file that reads "60 2F 0F 1B 00 00 00 00". In the hex editor I call this a QUAD and it converts to the decimal value of "453980000". I then lop off the ending four zeros and have the real number that I want. In my PowerBASIC TYPE, I used QUAD as the variable type too, convert it to a string and lop off the last four zeroes before displaying it. Sweet, same number.

    My method is working; but, something doesn't feel right to this process and I'm curious if my ignorance is blinding me.
    Donnie Ewald
    [email protected]

  • #2
    Don,
    it would be quicker to divide your quad by 10000 instead of manipulating it as a string.
    Code:
    x&&=&h000000001b0f2f60
    PRINT x&&\10000
    Paul.

    Comment


    • #3
      Thanks Paul, that makes more sense than what I've been doing.
      Donnie Ewald
      [email protected]

      Comment


      • #4
        Methinks that might be a decimal-scaled binary with a scale of four: "X AS CUR"
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          Greetings Michael!

          I've not used the Currency variables before. I did some reading in the PB help file and I wrote a small example for me to play with and see how the numbers react. This appeared to be perfect. I loaded up my original TYPE and changed the definition from "AS QUAD" to "AS CUR" and the results are exactly as I want--no further conversion or division needed.

          Much thanks, Michael. It's always nice to learn something new.
          Donnie Ewald
          [email protected]

          Comment


          • #6
            CUR types are really handy for the kind of applications I do so I use them a lot.

            Basically the only "decimals" I ever use are are prices, quantity and extension - two places after the decimal is sufficient for quantity and perfect for dollars and cents.

            Avoids all the rounding crap you get with any of the floating point types (SINGLE, DOUBLE or EXT).
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              Fine, if you know they are quads, but what if LONGS?

              If values are DWORDS division by 10000 may not work.
              Changed to a negative in this example.
              Code:
              #COMPILE EXE
              #DIM ALL
              'DWORD MAXIMUM       4,294,967,295
              $EDITOR  = "60 2F 0F 1B 00 00 00 00"
              FUNCTION PBMAIN () AS LONG
                LOCAL q AS QUAD, l AS LONG, d AS DWORD
                q = -453980000
                l = q
                d = q
                ? "QUAD"  + STR$(q\10000)  + "  " _
                  "LONG"  + STR$(l\10000)  + "  " _
                  "DWORD" + STR$(d\10000)
                SLEEP 2000
              END FUNCTION
              Last edited by Mike Doty; 28 Dec 2008, 11:26 AM.
              How long is an idea?

              Comment


              • #8
                Fine, if you know they are quads, but what if LONGS?

                The logic with 10000 might be okay since DWORDS can't be negative.
                Last edited by Mike Doty; 28 Dec 2008, 11:37 AM.
                How long is an idea?

                Comment


                • #9
                  Code:
                  Function PBMain
                      
                    Local q As Quad
                    Local p As Dword Ptr
                    
                    q = &h000000001b0f2f60
                    p = VarPtr(q)
                    ? Format$(@p[0])
                   
                  End Function
                  kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

                  Comment


                  • #10
                    "LONG" and "DWORD" are concepts of convenience only.

                    Each is a 32-bit binary integer.

                    The only "difference" if you want to call it that is the treatment of bit 31. When you read or write "as long" bit 31 is a sign bit; when you read or write "as dword" bit 31 is interpreted as just another binary digit conveying magnitude. (FWIW: BIT = BInary DigiT).

                    This is one reason why using inline numeric literals without type-casting is a bad habit to aquire: if the compiler assumes "LONG" instead of "DWORD" any arithmetic you do may be off by both the sign and the magnitude.

                    eg

                    NOT "q = &h000000001b0f2f60"; rather, "q = &h000000001b0f2f60<something>

                    What does the compiler use here? SINGLE, DOUBLE, EXT, QUAD, CUR and CUX will all hold the value

                    Better to use "q = &h000000001b0f2f60 {&&|!|@|@@|#|##} " here to eliminate any 'bad guesses' by the compiler.

                    MCM
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      Originally posted by Michael Mattias View Post
                      "LONG" and "DWORD" are concepts of convenience only.

                      Each is a 32-bit binary integer.
                      MCM
                      REALLY, do you know the difference between "two's complement" and "one's complement". There are a lot of extra transistors on you CPU chip to give you that convenience. One is a 31 bit signed integer, the other is actually a 32 bit positive only integer.
                      The compiler must know which it is dealing with to create the correct (very different) instructions to handle what are two totally different numeric types.

                      Comment


                      • #12
                        When a "LONG/DWORD" is returned from a WinAPI function, you get 32 bits. Read ("cast") it as you will, consistent with the rest of your program.

                        When passed by value as a parameter, all 32 bits are pushed on the stack. When this is a variable, you have controlled all those bits in your assignment statements. When passed as an expression or untyped literal , you haven't.

                        And yes I do the difference between ones complement ("NOT") and twos complement ("NOT" plus 1, discarding any overflow). And because the compiler knows, too, it knows which math routine to use depending on an operand's stated variable type.... which means you have just made my point for me.

                        Which is, "programmer is responsible for selecting the correct data type for the application and relying on defaults is a stone loser so don't use expressions or untyped numeric literals unless you can live with any sin you might commit however inadvertently."

                        MCM
                        Michael Mattias
                        Tal Systems (retired)
                        Port Washington WI USA
                        mmatti[email protected]
                        http://www.talsystems.com

                        Comment


                        • #13
                          Thank you Michael it seems you do know a little programming, so why would you say that
                          'bad guesses' by the compiler.
                          A single also only uses 32 bits, is that a "matter of convenience" too? They also push 32 bits on the stack etc so what has it got to do with WINAPI functions.
                          Last I looked nobody yet has built a computer or compiler that can accurately guess what the programmer was thinking, so why are you posting about compilers "bad guesses"
                          Old saying "put mind in gear before opening mouth" so why would you post to younger and mayby less experienced programmers that the only difference is bit 31 as a sign bit which takes us back to the dark ages of having +0 and -0
                          Regards
                          John

                          Comment


                          • #14
                            ... why are you posting about compilers "bad guesses"
                            So the younger people don't fall into the habit of allowing the compiler to make them!

                            (FWIW although it could/will/should bore the snot out of that same audience: when you cast your 32 bits "AS LONG" bit 31 IS a sign bit: when set, you must take twos complement and negate to obtain magnitude. When cast "AS DWORD", you have to treat bit 31 as a significant digit. I suspect we have semantic rather than substantive differences here).
                            Michael Mattias
                            Tal Systems (retired)
                            Port Washington WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #15
                              Originally posted by Michael Mattias View Post
                              So the younger people don't fall into the habit of allowing the compiler to make them!

                              (FWIW although it could/will/should bore the snot out of that same audience: when you cast your 32 bits "AS LONG" bit 31 IS a sign bit: when set, you must take twos complement and negate to obtain magnitude. When cast "AS DWORD", you have to treat bit 31 as a significant digit. I suspect we have semantic rather than substantive differences here).
                              Sorry can't agree, compilers never make guesses ( at least not on this site) they follow very strict rules. If you post that it is a matter of convenience or guess then you do this site a great disservice so please think before you post

                              Comment


                              • #16
                                > compilers never make guesses ( at least not on this site) they follow very strict rules.

                                You're right. It's just that they SEEM like guesses when you can't find those very strict rules in the documentation. (Even worse when you know those very strict rules are there somewhere).
                                Michael Mattias
                                Tal Systems (retired)
                                Port Washington WI USA
                                [email protected]
                                http://www.talsystems.com

                                Comment

                                Working...
                                X