tanhֿ¹(.9999999999999) returns "ERR:DIVIDE BY 0" … interesting. :) Apparently the calculator checks for something exactly being greater than or equal to 1, even though 1-.9999999999999 (which occurs in the defining expression for tanhֿ¹( is already 0 in the calculator.
Date: 18 Mar 2010 07:21
Number of posts: 9
RSS: New posts
In a different form: .5ln(2/(1-X)-1
So that's where the new error comes in. The ERR:DOMAIN does appear to be a manual check employed before rounding.
And again I must wonder what the developers were thinking when they decided not to include the complex field. Strange.
They bothered to include support for complexes in the 85, 86 and the 68k calculators, so indeed it is strange… which brings me to a question: can somebody try this thing out on a 68k calculator and report back?
I tried it on the Voyage 200 my teacher loaned me to experiment with, and it does indeed work fine!
I checked on my 86 and it works fine on it too. =)
Find more info about my projects on Omnimaga:
I checked on my ti92, and it works fine, as well.
What is the "it" you three are testing? We know they can handle imaginary numbers.
The question was: Do the calculators perform a forced boundary check on the argument of a hyperbolic function before they even begin to evaluate it? It's not about whether they can process a response, but whether they prematurely opt-out of doing so based on some hard-coded tolerance, akin to what was discovered on the 83+ above.
The thing we're looking for here is an error, not a success.
Thornahawk said "which brings me to a question: can somebody try this thing out on a 68k calculator and report back?"
I don't see how it is wrong of me and some other people to respond to his request. Forgive me for being nice, or something…
This is like a chemistry teacher asking his class to mix two compounds together and describe the salt that is produced, and then all of his students hand in papers that say: "It works."
What did you try, and how did the calculator respond? Please bear with me.