71B: DIM a variable, but keep the old value if it's already the right type?

[Dave Britten]

Suppose I've got a BASIC program that prompts for a few variables, and then runs some calculations on them. A hypothetical example would be a binomial distribution program. I'd like to have the program - by way of something like INPUT "X? ",STR$(X);X - 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. 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.

How might the 71B experts approach something like this? 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. 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?

[Joe Horn]

(03-23-2021 01:08 AM)Dave Britten Wrote:  ... 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.

How might the 71B experts approach something like this? 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. 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?

The "HP-71 Reference Manual" says the following about the DIM command:

"If DIM specifies a simple numeric variable that already exists, the variable is reinitialized to zero. Other variables are redimensioned, but not reinitialized (unless the data type -- or, if a string variable, the maximum string length -- is changed). If DIM expands an array, it also initializes all newly created elements in the array."

Therefore, just make sure that the desired array already exists and contains the desired data type. Then using DIM to redimension it will not clobber its existing contents (unless redimensioned smaller, obviously).

[Valentin Albillo]

.
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.

[J-F Garnier]

To answer the question in the title: "DIM a variable, but keep the old value if it's already the right type?", I would also use the TYPE keyword as Valentin suggested but the Math ROM is required.

An other solution, w/o Math ROM:
10 ON ERROR GOTO 30
20 X=X @ GOTO 40 ! check that X is a scalar variable
30 REAL X ! declare X of the right type if needed
40 OFF ERROR

J-F

[Dave Britten]

Cool, thanks guys. I should have mentioned that I'm aware DIMing an array/matrix won't clear its contents (unless you're shrinking its size or changing its type); it's more the scalar variables I'm worried about. DIM/REAL etc. will zero them out even if they're already the correct type. And it's just the variables that the program would be using as input prompts that I would like to retain, so that the values used during the previous run of the program can be presented as defaults on subsequent runs.

I hadn't dived into the Math ROM yet, so didn't know that TYPE() was available. As a matter of fact, I was looking through the 71B manuals last night trying to determine if there was something like that built in. I've got the MultiMod at my disposal now, so I'll probably use the IF TYPE(X)<>... approach in cases where I'd like to reuse a value if it's still available, but the data isn't important enough to bother storing in a file.

Granted, if the number of input variables gets large enough - say, more than six or so - it's probably less code to just save/load everything in an SDATA file.

[Valentin Albillo]

.

(03-23-2021 11:46 AM)Dave Britten Wrote:  I hadn't dived into the Math ROM yet, so didn't know that TYPE() was available. As a matter of fact, I was looking through the 71B manuals last night trying to determine if there was something like that built in.

TYPE should have been built-in, as it's so basic and essential a function that's very difficult and expensive to duplicate in BASIC code (lest you PEEK at various locations), and further it would take very few bytes in the System ROMs to implement it.

But they didn't because they needed those few bytes and several thousands more to implement instead the useless abomination known as "CALC" Mode just to satisfy marketing idiots and someone's ego. So poor TYPE was relegated to the Math ROM which, while being a fantastic, über-essential add-on, a real must, it also has its share of very questionable decisions in its implementation.

Quote:Granted, if the number of input variables gets large enough - say, more than six or so - it's probably less code to just save/load everything in an SDATA file.

The CALL approach is also very workable and preserves every variable under the (main environment) sun, and there are several other very different approaches to solve the problem (*cough* TRANSFORM *cough*) but you're probably well served right now.

Regards. [P.S.: glad you liked my HP-41C vs SHARP PC-1211 comparison article]
V.