Non-numeric stuff in calculations

[Walter]

Sometimes you come across nasty stuff in calculations, stuff like poles or 0/0, for example, where you're simply unable to tell a definite numeric result. Smart people invented NaN ("Not a Number") to cover such cases. So they can now proudly write tan(90°)=NaN and ln(-5)=NaN and 0/0=NaN etc. That's a nice and compact method for signalling a calculation "went off track".

If you get such a result in manual operation of your calculator, you may frown but usually know immediately what you did wrong. If, OTOH, such a result is returned by a routine, it may cost you some time and effort to find its origin - then you will try avoiding this "error" case in future by applying suitable means.

Now the question: Will you ever throw such a NaN result into a subsequent calculation?
I.e. put something non-numeric into a numeric procedure? If true, why?
Of course you can, and I've seen some academic examples where this was done - but does anyone know a real-world problem where this turned out advantegeous or beneficial? (No computer science but down to earth, please.)

Thanks in advance for your answers!

[Thomas Okken]

Propagating NaNs is useful for heavy number crunching, like anything involving large matrices. You just look for NaNs in your final output (and for infinities), and save yourself the cost of performing error checks on all your intermediate results.

[budmur]

Walter, that's a really intriguing question, and I really had to think about it. I'm a Civil Engineer, so in real life there's really no way to encounter a NaN that's not an error, so I started thinking about your question more abstractly.

I encounter the inverse pretty regularly- that is, I find terms that are so nearly zero compared to the other variables I can safety ignore them. But your question made more sense when I thought about times where I had to make an educated guess about something unknown, and it drove my results to the point where the answer got "silly".

A recent real-world example I encountered was the conceptual cost of a new water tank. I had a good idea of how large a tank I needed, along with the height of the tank. I didn't know the actual location of the tank, and that was considerably above my pay grade. The location depended on things like land acquisition costs, aesthetics, local neighborhood pushback, etc. When I did the cost estimate, the price of installing roads and water mains (plus the costs of attaining easements and upsizing water main size for longer distances) far overshadowed the cost of the tank itself. It was something like a 500% to 1000% cost swing depending on where they actually put the tank.

[pauli]

Programs are the main use case for me. Thomas's suggestion of matrices is another -- not all elements will necessarily become NaN's. Solve, integrate and the derivatives can also benefit -- the 34S derivative code uses 4, 6 or 10 point estimates. Infinite or NaN results are handled (I hope

[Dani R.]

I would even expand on the question a little. Is it correct that a calculator returns the reciprocal of +/-0 as infinity? Well, I can still imagine this (, the result, not infinity). But can the result infinity be used in another calculation? Specifically, is it correct that now the reciprocal of infinity gives a result of 0?

EDIT:
I must apologize once more. Of course, you can only see this behavior if flag 107 (FLAG_DANGER) is set. But the question remains, is the reciprocal value of infinity allowed to give a result of 0?

[H2X]

Will you ever throw such a NaN result into a subsequent calculation?

Not without preserving any information about why it's not a number.

[Jaymos]

From a practical point of view for me it is essential that in a formula compromised of sequential RPN steps, that no one step will result in a hard error, regardless how bad the error is, because that will require manual intervention and stop the process.

When you graph or solve for roots of f(x) = sin (x) / x - 5 x ^2 + x between -pi and pi, you expect a continuity issue at x = 0 where in fact you are really not interested in that point on x. Flagging a result to be able to handle it at the end, or not even handle it in case of a graph, is essential.

The above RPN example of ENTER ENTER ENTER SIN X<>Y / X<>Y SQR 5 * - + would require the fnSubtract and fnAdd functions to be able take as an input, the 0/0 result of the divide by 0. If you would not, the first function with 0/0 would throw an error. And the graph stops. Or the root find stops.

In another example I wrote of yesterday, in viewtopic.php?f=2&t=2216&start=670, I plotted f(x) = (sin(x)/x + sin(10x)/5) / 2 + 2/x which had two issues, fortunately not stopping the plot function at 0, for 0/0 and 2/0.

[H2X]

From a practical point of view for me it is essential that in a formula compromised of sequential RPN steps, that no one step will result in a hard error, regardless how bad the error is, because that will require manual intervention and stop the process.

When you graph or solve for roots of f(x) = sin (x) / x - 5 x ^2 + x between -pi and pi, you expect a continuity issue at x = 0 where in fact you are really not interested in that point on x. Flagging a result to be able to handle it at the end, or not even handle it in case of a graph, is essential.

The above RPN example of ENTER ENTER ENTER SIN X<>Y / X<>Y SQR 5 * - + would require the fnSubtract and fnAdd functions to be able take as an input, the 0/0 result of the divide by 0. If you would not, the first function with 0/0 would throw an error. And the graph stops. Or the root find stops.

In another example I wrote of yesterday, in viewtopic.php?f=2&t=2216&start=670, I plotted f(x) = (sin(x)/x + sin(10x)/5) / 2 + 2/x which had two issues, fortunately not stopping the plot function at 0, for 0/0 and 2/0.

I see your point totally, but that's not quite the same as throwing that result into a subsequent calculation, though?

[Jaymos]

Hi

In the example above the ‘erroneous’ result is going in as an operand into the Subtract function as not a number, is expected not to halt, out again into X, and into the next function, the Add, again as not a number.

The OP referred to a practical example of a not number going into a function. This is one.

J

[Thomas Okken]

From a practical point of view for me it is essential that in a formula compromised of sequential RPN steps, that no one step will result in a hard error, regardless how bad the error is, because that will require manual intervention and stop the process.

That could be dealt with using an exception-handling mechanism. The HP-42S does this in SOLVE, where any occurrence of Out of Range, Divide by 0, Invalid Data, and Stat Math Error, in the function, results in a non-local exit back to SOLVE.