In high school, I was pretty fond of plugging 11^n to get rows of Pascal's triangle. It breaks down at row 5, but inserting 0's in the middle extends it (e.g. 101^n, 1001^n, 10001^n).
On most pocket calculators, 11111111×= will yield 12345678. People are often surprised that that sequence is accepted. To me, it exposes something about the calculator's internal architecture.
It's also a useful self-test if you think the battery might be going.
The sequence is a shortcut accepted by the vast majority of regular calculators for most of operations. It simply takes the second operand to be the same as the first and repeated pressing of the = key repeats the operation ad infinitum. Ie. 1+== is 3.
I have written an iOS calculator app and had very interesting times trying to find and mimic these shortcuts. I have thought for a long time they had to follow from some simple implementation detail, as all the calculators got them precisely the same, but I never found this one consistent rule, I had to implement the features in a series of hacks.
This site [1] reveals the secret to that pocket calculator shortcut and a few others, and also provides useful algorithms for calculating things such as square roots and logarithms.
Wonderful! That site gives tests that can be performed from the keyboard to distinguish between Casio and non-Casio architectures, mentions the invisible 9th digit of precision, and notes that some calculators get it wrong.
The old Sinclair pocket calculators had some known arithmetic inaccuracies.
Well, clearly the display is an addressable register, not merely an output through a latch.(I say that because I assume the design goals of an inexpensive calculator include kaizen-ing the bill of materials down to the absolute minimum. So it's probably a visible register. Similarly, it's probably a digit-serial architecture (maybe BCD), also for parts count reasons, but yielding supplemental advantages when it comes to verification.
Different operations take noticeably different amounts of time; a "timing attack" like those used for cryptanalysis might yield clues to what's in the black box.
The way new digits appear on the display when typed in suggests it might be implemented as a shift register. It would be interesting to look at high speed video of the display when the answer to a long computation appears; do the answer digits appear (rapidly) one at a time? Do they shift in from the left? Three caveats: (1) I've never noticed it happening; (2) LED displays are almost always multiplexed, but you could probably see through that; and (3) probably wouldn't work on an LCD because too slow. I used to have a vacuum fluorescent display calculator, though; IIRC it was not multiplexed.
There are a few articles on the web about the architecture of calculators, including the Busicom [1] and Sinclair [2].
Personally, I want to hear more about zoul's research---how did you do it?
While bored in middle school algebra, I figured out on my TI-30 which number, raised to itself as a power, would equal 9.9999999E99 (not sure on the precise number of nines after the decimal point, but basically it flooded the screen with all nines).
56.96124843225 ^ 56.96124843225
Wolfram confirms that it's pretty close to a full googol. Of course, you can keep adding digits to the end of the number to make it even more precise. Maybe I'll write a script to do that.
I was wondering if there was an inverse operation for tetration, and it turns out there is: https://en.wikipedia.org/wiki/Tetration#Square_super-root (what you're basically finding is 56.96124843225⇈1, which is apparently ssrt(1googol))
It actually doesn't break, you just have to do the carries as you would during normal addition. You have to read from right to left (1's place, 10's place, 100's place, and so on). So you're really just converting to base 10.
You can of course do this trick in any base. If we choose e.g. base 2^n for the n-th row of pascals triangle, we can use the following code for getting the n-th row of pascals triangle:
def pascal(n):
base = max(2, 2**n)
row = (base+1)**n
return [row/base**i % i for i in range(n+1)]
Nice, but hopelessly inefficient. :) You can also calculate a binomial coefficient the same way without any looping construct (the exponential operator does the looping for you).
We had a calc problem in high school on a test that would get you extra credit if you simplified the answer down to... something simple, and in order to do so you'd have to know Pascal's triangle.
Needless to say, I didn't get it, but one guy in our class, like an 8th grader, did. He was pretty smart.
