Post Reply 
71B: DIM a variable, but keep the old value if it's already the right type?
03-23-2021, 03:06 AM
Post: #3
RE: 71B: DIM a variable, but keep the old value if it's already the right type?
.
Hi, Dave Britten:

Dave Britten Wrote:Suppose I've got a BASIC program that prompts for a few variables, and then runs some calculations on them. [...] I'd like to have the program [...] provide the previous values so that I could tweak one or two of them, and keep the rest the same. Much like INPUT on the 42S.

So far, so good. Let's call this program "A".

Quote:But I'd also like to make sure that the variables are the correct types, and haven't been left as arrays or some other inappropriate types by a different program. If I use DIM or REAL to make sure they are the correct type, this zeroes them out, even if they were already REAL variables to begin with.

So you want to be able to run program "A", then run programs "B", "C", ..., and then run again program "A" but making sure that the input variables still keep at least their correct types, despite the fact that programs "B", "C", etc., may have destroyed them and/or re-declared them with different types than the ones used by program "A". Correct so far ?

Quote:How might the 71B experts approach something like this?

I don't know how the 71B experts would approach this but I'll give you several options, read on.

Quote:I know I can write the input values to an SDATA file and retrieve them at the beginning of the program, and I've done this for programs where it makes sense to keep the values indefinitely between runs.

Sounds good.

Quote: But is there a simpler option for when I don't care if one of the variables gets clobbered by another program I've run in the meantime?

This I don't understand. If one of the variables program "A" uses gets clobbered by program "B" (i.e., destroyed or re-declared), wouldn't this speak trouble when you re-run program "A" ? Wouldn't this result in an error when program "A" tries to use variable P, which was a simple REAL type but now is a matrix ? Also, doesn't program "A" declare the variables itself ? I find this weird.

Never mind. You may try these options:

Option 1 - In program "A", check the type of every variable you're interested in and re-declare it if that's not the type you need, like this:

      10 IF TYPE(X)#0 THEN REAL X
      20 X=71 @ DISP X


Line 10 checks if variable X is a simple real variable (i.e., INTEGER, SHORT or REAL) and if it isn't it redeclares it as a simple REAL one. To check that this works, line 20 assigns a value to it and displays it. Test it by doing this from the command line:

      >DIM X(5,5) @ RUN -> 71 , which is the value assigned to the re-declared variable X.

The types are:

      0    simple real (INTEGER, SHORT or REAL precision variables)
      1    simple complex (COMPLES or COMPLEX SHORT precision variables)
      2    simple string
      3    INTEGER array
      4    SHORT array
      5    REAL array
      6    COMPLEX SHORT array
      7    COMPLEX array
      8    string array


This will set the types straight as your program "A" wants them but their previous values might have been lost or modified when running programs "B", "C", ...


Option 2) - You can take advantage of the different separate environments the HP-71B can hold at once by executing the programs in this fashion:

      - RUN program "A". This uses the main ("calculator") environment.

Now you need to run program "B" and then program "C" but you don't want them to disturb program "A"'s variables and their values. You can achieve that by CALLing them instead of RUNning them, like this:

      - CALL program "B". This creates a different environment for program "B", which gets terminated when program "B" ends. Program "A"'s environment is unaffected.

      - CALL program "C". This creates a different environment for program "C", which gets terminated when program "C" ends. Program "A"'s environment is unaffected.

At this pont, all variables of program "A" remain unaffected, their types and values intact and you can RUN (not CALL) program "A" again and use them. As long as you execute other programs using CALL instead of RUN, they won't affect program "A"'s variables. By the way, you don't need to do any changes to programs "B", "C", etc., any program can be RUN or CALLed without requiring a SUB declaration or parameters or END SUB or anything else.

Hope that helps.
V.

  
All My Articles & other Materials here:  Valentin Albillo's HP Collection
 
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: 71B: DIM a variable, but keep the old value if it's already the right type? - Valentin Albillo - 03-23-2021 03:06 AM



User(s) browsing this thread: 1 Guest(s)