HP Forum Archive 17

[ Return to Index | Top of Index ]

Testing UserRPL arguments for numerosity? Message #1 Posted by Sleazey on 16 May 2007, 5:58 p.m. I am writing a package of routines to do both algebra and numeric calculations using the generalized hypergeometric function. If all incoming parameters are numeric, or can be evaluated to numeric, then for some ranges of the parameters, I can return a numeric result. However, if a parameter is a symbolic, and cannot be evaluated to a numeric result (like an undefined global name, etc.) then I can't return a numeric result, (but I may be able to return a simplified symbolic result). Here comes the question: What's the best way to validate/evaluate/check/test incoming parameters for "numerosity"? That is, what's the best way to test a parameter to see if it can be resolved to a numeric value? Is there any kind of built in UserRPL function (or even a SYSEVAL) that does this kind of thing? Right now I have a long CASE statement that checks various TYPE values, and returns true/false. That works ok, but it's not very fast. Complications come in because an algebraic expression may be evaluable down to a numeric result, and I would like to handle that case correctly too. Global names may have a numeric value; need to handle that too. Perhaps a global name refers to another global name, that refers to another global name, that refers to a numeric or an evaluable algebraic; that should count as a numeric parameter too. Would it be better just to attempt to do an EVAL and/or a ->NUM against a parameter (guarded with IFERR) and see if that results in a numeric? Would that be definitive? Thanks for any suggestions!

Re: Testing UserRPL arguments for numerosity? Message #2 Posted by hugh steers on 18 May 2007, 4:13 a.m., in response to message #1 by Sleazey what goes wrong if you just eval it? is it the error trapping?

Re: Testing UserRPL arguments for numerosity? Message #3 Posted by Sleazey on 18 May 2007, 2:20 p.m., in response to message #2 by hugh steers Actually I have something that works for all the cases I have tried. It ended up being a very long IF test, with some recursive calls to itself. I also use IFERR extensively to catch errors during EVAL & ->NUM; if an error occurs, I just return a false result (treat it as non-numeric). So, I do have it working, but it's slow, looks a bit inelegant, and I worry about obscure or rare combinations that could slip through the cracks. I just keep using it in my code; that will be the only way to thouroughly test it. I looked in the SysRPL manuals, but didn't see anything quickly that looked what I wanted.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall