Ok, so before i explain, let me give you my specs . I found this error whilst running wabbitEMU android. I've tested it with the 84+, 84+se, 84+cse. (note that they are all on wabbitEMU android.
Anyways, here is the problem: when i do log(16,2) it returns 4. Good. Thats what its supposed to do. But when I try to apply an int(, iPart(, or fPart(, the number is revealed to be not 4, but 3, with a fpart of 1, an impossibility. Any answers?

Here's the homescreen output:

Code:

What happens if you test the same thing in jsTIfied in your browser on your phone? What calculator model and OS version is it?

I just tried it on my 2.55MP TI-84+SE and can confirm this behavior.

I stated the emulated calcs above. Their OS versions are the latest available from TI. I don't actually own a ROM image, I've been using wabbitEMU's generator. I see your line of thought, that maybe there's an error in the app itself. At the moment, I have no way of testing that hypothesis, however.

On further testing, for int(log(x,2)) x=2^9 also errors, as well as x=2^34, x=2^35, x=2^36, and x=2^37.

Yep, something weird is going on.


(Edit: it's precision issues, probably, since with 16.000001, for instance, it's good)

This is a long-standing bug in iPart/fPart. I've had problems with it going back to early (read: pre-MathPrint) versions of the 84+ OS. I've never had much success in replicating the problem, but generally have steered clear of using those functions anywhere mission critical.

The calculator calculates/stores numbers with 14 digits of precision, but only displays 10. This allows for small errors in computational algorithms to occur and even propogate a fair amount without affecting the result visible to the user.

But when you start using operations that rely on all 14 digits to make decisions, like int(), iPart(), or fPart(), these tiny, invisible errors can become visible. And this is what you're seeing, because the logarithm algorithm isn't always correct to 14 digits. The actual result the calculator produces for log(16,2) is 3.9999999999999, off by one in the 14th digit. But this tiny error results in the integer part being 3 and the fractional part being 0.9999999999999 (which, when rounded to 10 digits for display, is 1).

Since the error is from some rounding off issues, you could always add in a round( command to fix it...

But then again, I have a hard time imagining any situation in which one might need functions that look like this...

This is definitely a precision error.
TI-89 Titanium:

Code:

It happens on the 83+ (running 1.13) using change-of-base.

Thanks for the detailed explanation Runer112. It's a shame that calculators have errors like this that are hard to detect.