Announcement

Collapse
No announcement yet.

Who knew this -- CHOOSE$ nested inside a VAL

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

  • Who knew this -- CHOOSE$ nested inside a VAL

    Greetings ...

    Within the last week I made what was for me a fascinating discovery. It is a programming trick that is apparently not officially documented in the PowerBasic HELP files (at least as far I can determine), and something which I had simply never tried before.

    This involves the nesting of the CHOOSE$ string function within a VAL Function. Here's an example ...

    Code:
    For KKount=1 to 8
        NXAA=VAL(CHOOSE$(KKount,"25000","10000","5200","5100","5000","1400","500","25","00","00")+"000")
        IF NXAA <24 THEN EXIT FOR
        GeeNumber(KKount)=NXAA
     Next KKount
    This works with the two Console Compiler versions I have, PBCC4 (4.04) and PBCC5 (5.05). I assume that it will also work in PBCC6 and most versions of PBWIN as well. It follows a basic rule for the VAL function, the supplying of extractable numeric data -- and ONLY numeric data -- embedded in a string. Also, the number of available item choices is kept under control so that no error occurs.

    While there may be better programming methods than what I have presented here, it may still be of use in certain scenarios. In my case, this method helped to greatly reduce the size of an include file (.inc) in one of my programs.

    BTW -- I did not start using CHOOSE$ until PBCC4 came out. I had previously used PBCC2 and I don't recall if CHOOSE$ was a part of that version. When exactly was CHOOSE$ added to Console Compiler ???

    Thanx-A-Lot. Stay Safe and Well.



  • #2
    That behaviour is to expected. CHOOSE$ returns a string, VAL converts it into a number.

    It's just an inefficient way of doing this:

    '
    Code:
    FOR KKount=1 TO 8
        NXAA=CHOOSE&(KKount,25000,10000,5200,5100,5000,1400,500,25,00,00) * 1000
        IF NXAA <24 THEN EXIT FOR
        GeeNumber(KKount)=NXAA
     NEXT KKount
    '

    Comment


    • #3
      Stuart McLachlan OK! Thank You.

      Question -- If the NXAA variable has been defined as EXT (extended precision), then would not each number in the CHOOSE list, as well as the * 1000, need to have ## appended to the end of them ??

      Thanx-A-Lot.

      Comment


      • #4
        Originally posted by Frank Ferrell View Post
        Question -- If the NXAA variable has been defined as EXT (extended precision), then would not each number in the CHOOSE list, as well as the * 1000, need to have ## appended to the end of them ??
        Thanx-A-Lot.
        In a word - "no"

        Buried deep in Help, you will find this statement ( under "CBYT, CCUR, ... functions")

        PowerBASIC automatically performs any necessary conversions when executing an assignment statement or passing parameters


        Comment


        • #5
          BASIC in general does a lot of things for you.. eg you do not have to explicitly define ("DIM") variables before using them or convert datatypes for arithmetic - see Stuart's post #4 above..this is yet another 'automatic' conversion performed by the language product.

          Try some of the things supported in BASIC in other languages and you will get lots of compile-time and/or runtime errors.
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Michael Mattias
            Stuart McLachlan

            The Powerbasic language may indeed automatically compensate for certain processes, but you can still get errors if certain elements do not work together right. So, I have become more observant and careful when coding with EXT variables. Learning what I've learned in this particular thread will be helpful.

            CHOOSE (plain, & or $) is a wonderful addition to the BASIC dialect and has helped simplify coding in many situations. As Michael noted above, it does allow a variable to operate as if it had been DIM'd.. Still, you may have situations where it is necessary to use DIM'd variables and CHOOSE together. For me, it is the perfect replacement for the old GW-BASIC Read-Data-Restore routines.

            One last thing before I sign off on this topic -- while Powerbasic allows CHOOSE$ within VAL, it does not (in my experience, at least) allow the nesting of CHOOSE$ or the incorporation of string data returned from a Function into a BUILD$ process. Here, string data from a CHOOSE$ or from a returned function must be processed and stored in variables outside of a BUILD$, and then those variables can be incorporated into the BUILD$. That's the case in PBCC5 - I can not speak for PBCC6 or PBWIN.

            Thanx-A-Lot. Stay Safe and Well.

            .

            Comment


            • #7
              Originally posted by Frank Ferrell View Post
              One last thing before I sign off on this topic -- while Powerbasic allows CHOOSE$ within VAL, it does not (in my experience, at least) allow the nesting of CHOOSE$ or the incorporation of string data returned from a Function into a BUILD$ process.
              Documented in Help:

              "In order to extract the utmost efficiency, BUILD$() was designed to work with a very narrow definition. The component parameters must be dynamic string variables, either scalar or array, string literals, or string equates. They may not be expressions."



              Comment


              • #8
                Stuart McLachlan Thanks. I had probably seen that many times, but had not gleaned its exact significance .

                RE a reply of yours prior to this last -- In a golf purse program of mine, which generates individual place prizes for most PGA Tour events, there are SUBs where I use a combination of STATIC DIM'd variables in concert with a CHOOSE list to process and store data for future callbacks to the same SUB for on-screen display, printing to hard copy or PDF, or saving to a text file. In contrast to your remark that the appending of the extended-precision ## marks to each numeric item isn't necessary, I discovered that doing so anyway fixed occasional alignment errors of the outputted data.

                Thanx-A-Lot Once Again.

                Comment


                • #9
                  , I discovered that doing so anyway fixed occasional alignment errors of the outputted data.
                  ??

                  If by "output alignment" you mean the way columns of figures are displayed or printed....

                  Output alignment issues have nothing to do with datatypes, mixed mode arithmetic or rounding.

                  Output alignment is "Output alignment" and is a fundamental programmer skill requirement.

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

                  Comment

                  Working...
                  X