following the hype of the 71b math rom (which i dont have), im interestered to know how to write a function that takes another function parametrically by reference. for example, the math rom will accept something like,
integral(0,1,5e-5,cos(1/ivar)) treating the `cos' part as a function definition. how does one define such a `integral' function.

the owners and reference manual for the 71b describes the way to pass variables by reference to subroutines. eg.

10 INPUT Y @ CALL FOO(Y) @ PRINT Y

20 SUB FOO(X)

30 X=X+1

40 END SUB

where FOO modifies the input variable. but i cant find the way to make it accept a function. is the math rom doing some extra cleverness here, or is there a way?

thanks for any help,

The math ROM is doing extra cleverness by virtue of integral being written in assembly as part of a LEX file (Language EXtension). AFAIK there's no way to do that in HP-71 BASIC using similar syntax.

There might be some other way to do an indirect call to a named subroutine to get a similar effect, but I don't remember.

I'm not sure I know exactly what you're asking, and I seldom do HP-71 programming anymore so I'm rusty at it; but I'll jump in anyway now.

From your post, I wonder if you're looking for user-defined functions instead of subroutines or subprograms. User-defined function calls take on the form of FNA(...) if you want numeric output, and FNA$(...) if you want a string output. They only give one output, and it's automatic unlike the subprogram which might have several outputs and passes them via the parameter list.

CALL is for subprograms, not subroutines. Subprograms have their own environments, and are even re-entrant, unlike subroutines. A BASIC file can have any number of subprograms in it, and a subprogram does not have to be in the same BASIC file as the program or subprogram that's calling it. If you have more than one subprogram with the same name and the one you want is not in the currently executing file, you'll need to tell the computer where to find it, either by file name, port name, or something like that. CALL can also be used to call an assembly-language program. An input parameter can be any expression that's valid for the type of variable it goes into in the subprogram; so if one of the input parameters needs to be a real number and V1 was a real variable, it would be perfectly valid to put your COS(1/V1) in the input parameter list (as long as you don't want the output to come through the same parameter-- outputs can't be stored in your expression since it's more than a variable). Parameters are separated by commas, and the parameter list goes in parentheses. You can have a variable or array name be both an input and an output parameter at the same time, which seems to be one of the things you're talking about. For example, even if you only have one parameter in the list, it can be both input and output.

Hi Hugh,

There are some solutions to your problem.
If you want to pass a function, you can pass it as a string, and use the VAL function:

SUB FOO(F$)

  Y=VAL(F$)

END SUB

E.g. CALL FOO("SIN(X)"), CALL FOO("FNF(X)")

SUB FOO(F$)

  CALL F$(X,Y)

END SUB

for instance, CALL FOO("MYFUNCT") with

SUB MYFUNCT(X,Y)

  Y=whatever function of X

END SUB

Hope it helps...

J-F

thanks for the replies. i understand now that the math rom must be doing some special cleverness. it just bugged me that there wasn’t some special way to accomplish the same using the standard basic implementation.

i think the string method is the most viable alternative in the absence of a special facility.

best regards,
-- hugh

Hi, Hugh:

Math ROM's keywords FNROOT and INTEGRAL are what HP-71B's original developing team call "funny functions", i.e.: they're functions with non-standard parsing rules, unlike regular functions.

For regular functions, the built-in parser simply evaluates the function's arguments (if passed by value) before pasing them in to the function. That's why you can simply give the number and type of the parameters when coding a new function in Assembler to be included in a LEX file. You don't have to do the parsing yourself, the standard parser will do it on your behalf.

On the other hand, "funny functions" need non-standard parsing, and if coding one in Assembler, you must do it yourself, the standard parser won't do. In the case of FNROOT and INTEGRAL, both accept a function which ultimately uses FVAR or IVAR as the main variable, and the Math ROM's non-standard "funny function" parser can check that FVAR/IVAR are indeed present in the function's definition, allocate space for them, allocate a buffer for the function passed as parameter, and call the expression evaluator upon the contents of this buffer as many times as needed.

Further, as both FNROOT and INTEGRAL can be nested with previous invocations up to 5 levels deep, as many buffers need be created and maintained (they can move around in RAM while FNROOT and INTEGRAL are executing), plus allow for user interruptions while the evaluation is in process, with the possibility of resuming afterwards.

All of this isn't particularly easy, and as stated, needs a very clever, special "funny function" parser, completely ad-hoc for the particular function at hand.

So no help from the mainframe in this respect, and writing one yourself (in Assembler) can get pretty tricky, to say the least.

Best regards from V.