Page 2 of 2

### Re: Non-numeric stuff in calculations

Posted: Sat Jan 04, 2020 11:25 pm
Thomas Okken wrote:
Sat Jan 04, 2020 7:18 pm
... Out of Range, Divide by 0, Invalid Data, and Stat Math Error ...
Nice examples of "information about why it's not a number" which I was referring to earlier.

@Jaymos, with an exception-handling mechanism in place, you'd be fine?

@Walter, I assume there is or will be one in the 43S?

### Re: Non-numeric stuff in calculations

Posted: Sun Jan 05, 2020 1:53 am
H2X

My example shows the need for handling of some sort, as long as an error doesn’t stop execution. Either way will work for that. The identification of the incoming operand number as a non-number and the handling-at every math function is one way of doing it, Preventing entry to math functions if the operand number is not defined as number, is another way.

Currently the 43S is allowing non-numbers passing through functions without crashing. My graph procedure therefore requires no special handling for the expected 0/0 state. I like it that way.

I do neither the spec nor the programming of the math functions in the 43S, and since I haven’t programmed the WP34S or HP42S or Free42, I cannot tell which way is most efficient, what the best is for the corner cases, and what the pros and cons of either way are, but you can read a lot more discussion on the GitLab 43S issues on this topic relating to the 43S.

J

### Re: Non-numeric stuff in calculations

Posted: Sun Jan 05, 2020 11:09 am
Jaymos wrote:
Sun Jan 05, 2020 1:53 am
H2X

My example shows the need for handling of some sort, as long as an error doesn’t stop execution. Either way will work for that. The identification of the incoming operand number as a non-number and the handling-at every math function is one way of doing it, Preventing entry to math functions if the operand number is not defined as number, is another way.

Currently the 43S is allowing non-numbers passing through functions without crashing. My graph procedure therefore requires no special handling for the expected 0/0 state. I like it that way.

I do neither the spec nor the programming of the math functions in the 43S, and since I haven’t programmed the WP34S or HP42S or Free42, I cannot tell which way is most efficient, what the best is for the corner cases, and what the pros and cons of either way are, but you can read a lot more discussion on the GitLab 43S issues on this topic relating to the 43S.

J
Thanks, Jaymos!