Calculator bugs

		Home New Stuff Author Links Guest book Web-log	Adverts Bric-a-brac Calculators Components Ephemera Events	For Sale Glossary History Hit or Miss Radios Transport	Ultra Vales Wanted Metal Puzzles Articles Clocks

Calculators: bugs, artefacts and styles

There are several reasons for this section on Vintage Calculators. It is interesting to see what mistakes the designers of the very early single-IC calculators made. It helps you to identify which IC a calculator uses without opening it, and.... its fun to play with your calculator! Let me know if you have discovered any more. I have broken this section down to three areas: Bugs (pure mathematical or process mistakes), Artefacts (strange behaviour in an uncertain areas) and Styles (how certain end conditions like overflows are treated). I hope, eventually to include a "Guess the IC" section based on this items. For the key of the symbols see Protocol below.

Bugs

Post Divide to Zero bug
ICs: TI TMS0851NC
Calculators: Eltex, Prinztronic 88P

This is rather odd. First take a number and divide by ten until it is zero. Then add a number and the trailing zeros are not suppressed. I suspect this is an artefact from an extra internal digit of precision.

Key sequence:	(1)(/)(1)(0)(=)(=)(=)(=)etc	“0.”
	(+)(6)(=)	“6.0000000”

Divide to Negative Zero bug
ICs: Toshiba
Calculators: Electronic Resources, Toshiba BC815

Two different outcomes for this bug I have found:

Key sequence:	(-)(1)(/)(1)(0)(=)(=)(=)(=)etc	“-0.”
or:		“-0.0000000”

Negative Zero bug
ICs: Hitachi et al
Calculators:

This allows you to display minus zero and is quite common. This bug doesn’t appear to affect the math of any subsequent calculation, mathematically it is treated exactly the same as true zero

Key sequence:	(1)(-)(2)(=)	“-1.”
	(+)(1)(=)	“-0.”

Pseudo Fixed Decimal Bug
ICs:
Calculators:

Calculators that do not normally have a switch for fixed decimal notation can sometimes be forced into almost acting that way. In this example the three trailing unsuppressed zeros stay during all addition and subtraction operations until more digits are required. I usually find that this condition is reset by using a multiply, divide, root or percentage function when normal operational display returns.

Key sequence:	(1)(+)(0)(.)(0)(0)(0)(=)	"1.000"
	(+)(2)(=)	"3.000"

Zero Square Root Bug ICs: Texas TMC0807 from 1975 / (TMS0855) from 1975 Calculators: Prinztronic Mini 7
Not such a common one so useful to discover the offending IC. It appears to affect certain calculations after using the square root and can even cancel the automatic constant function. Just one of those things that slipped through the design QA I guess. Funnily enough if you just try the square root of zero it is fine.

Key sequence:	(1)(-)(1)(=)	"0."
	(SQRT)	"0.0000000"
and try:	(0)(.)(1)(-)(0)(.)(1)(=)	"0."
	(SQRT)	blank display
and try:	(1)(0)(0)(0)(-)(1)(0)(0)(0)(=)	"0."
	(SQRT)	"0.0000"
(and want even more):	(1)(.)(0)(0)(0)(0)(0)(0)(1)(Sqrt)	"1."
	(-)(1)(=)	"-1."
and just to top it try:	(1)(SQRT)	"1."
	(-)(n)(=)(=)...	"-n." and constant is disabled

Artefacts

Divide by Zero artefact
ICs:
Calculators: Litton Royal

The vast majority of calculators will give you an error state if you try to divide a number by zero. There are two main deviations from this (a) the ignore and carry on bug and (b) the clocking digit artefact. Sometimes the standard error state is recoverable and sometimes it is not. To gauge this try pressing (CE) and (n)(=) to see if the error state is generated again after recovery.

Key sequence	(5)(÷)(0)(=)
Standard		Result "0", and error flag
(a) Ignore		"0" and calculations continue
(b) Clocking		"0a0c00" where c and a is a incrementing number

Protocol:

Items in brackets are key presses, i.e. 1+2 would be shown as (1)(+)(2)(=) they are given for normal logic unless the particular bug is in RPN logic only. If you see (n) then any number can be keyed in. Items in quotes are the display result; i.e. the above would show “3” or “3.” or “3.00” in fixed decimal mode.