The beginning of the thread "Bugs - Bugs and Bugs" (23 August 2007) asked "Do any of you have lists of the bugs in the other brands ...?"

I have been out of commission for about two months with health problems. I am currently in a watch and wait mode so I will try to belatedly respond to the question with some history of bugs in the TI product line and one bug in the Casio product line. The listing is representative but by no means comprehensive.

I recognize three kinds of "bugs". The first kind includes mechanical and electrical deficiencies. The second kind includes software and mathemattical errors.

The third kind includes characteristics of a machine which Richard Vanderburgh called "unannounced features" and Maurice Swinen called "quirks" . These "bugs" were of interest to users but their use was not always supported by the manufacturer.and sometimes even discouraged by the manufacturer. The TI user community became somewhat obsessed with these unannounced features. Sometimes the results were trivial as when one individual reported that on the SR-52 pressing read followed by simultaneously pressiing B, INV, sin, STO, EE, 4 and 0 would turn on the card reader drive motor.

Casio fx-7000G

The random number generator in the first graphic calculator was supposed to yield uniformly distributed random numbers. It yielded random numbers which were not uniformly distributed. The distributionn changed when the calling routine changed. The bug was fixed in the fx-7000GA. (V11N1P8 of TI PPC Notes)


There were anomalies in the trigonometric functions and the logarithmic functions. These were similar to those seen in the original HP-35. For example, in the SR-52 the sine of 89.9999999954 is returned as 1.00000000004. V2N2P1 of 52 Notes)


The keyboard had a severe bounce problem. It was so bad that when the TI-55III became available with an improved keyboard one only had to send in a TI-55II to receive a TI-55III in return.with no questions asked. Unfortunately, the defective keyboard was also used in the ,BA-55, the TI-57LCD and the TI-88.

There was a problem in the statistics routine such that if the user entered 4, 5, 6, 7, and 8 the mean would be displayed as 6 but the value in the machine was actually 6 - 1E-10 ! This was caused by use of a different algorithm for statistics accumulation where, for example, the sum of the input values was not stored, but rather the current mean and the number of entries was stored. V8N1P26-27 of TI PPC Notes).

The memory registers used for the statistics routines cannot be accessed using the published procedures. There was an unpublished procedure for viewing the accumulations which started by pressing and holding the R/S, square root and OFF keys simultaneously. (V8N2P21 of TI PPC Notes). .


Some devices had memory problems such that a stored number would not be correctly recalled. The Service Manual presented a program for testing for this problem. The user community found that some faulty memories would pass the TI test and devised a more thorough test.

Capacitor C-7 which is part of the card reading circuitry was occasionally improperly positioned so that it could be touched by the negative battery pack terminal when the battery pack was in place.

The diagnostic routine in the Master Library module and the Agriculture module would fail if the calculator was in the Eng mode. On other modules with the diagnostic routine an INV Eng sequence at the begining of the routine eliminated the problem. (TI PPC Notes V8N2)

If INV Sum+ is executed with the y value in scientific notation an error would occur vbecause at ehtry to the statistics routine the sign of the exponent would be changed rather than the sign of the y value (Page 7 of the V5N2 issue of PPX Exchange)


The advance publicity for the CC-40 said that it had a 3/4 size QWERTY keyboard which could be used for touch typing. A 3/4 size keyboard is a little small -- adult fingers don't fit kiddy keys -- but the real problem was that the ENTER key was where the right shift key should have been.

The Mathematics module had two programming errors. Thre was an erroneous prompt in the Edit routine and the determinqant of a matrix was occasionally of the wrong sign.


Touch typing was no longer possible. The keyboard was too small and the rows did not have a half key displacement between rows.

The AC 9201 Power Supply could only be connected if the printer was connected.

The two prograqmming errors in the CC-40 Mathematics Module were corrected in the TI-74 Mathematics module.


The AC 9201 Power Supply could only be connected if the printer was connnected.

An ASM routine would successfully convert a program with labels to a program with direct addressing. The INV ASM routine which was supposed to convert a program with direct addressing back to a program with labels did not always work properly.(V13N1P8 of TI PPC Notes) . ,


Sentry CA756

This is their high-end graphing calc: the package says "Compare with TI-83." I picked one up cheap to play with, not having played with anything comparable to a TI for decades.

sin(PI) gives zero. What's even worse is that int(PI) does not produce an integer. Apparently the built-in value for PI includes some extra guard digits and they don't get stripped out properly, leaving 3 + a small value.

int(acos(-1)) has a similar problem, as does int(x*PI) for many (but not all) values of x.

The random number generator isn't. Multiple invocations within a single program run return the same result, unless the program halts for display. Run the program a second time and you get a different number, which then repeats.



sin(PI) gives zero. What's even worse...

Shouldn't it?


Does your calculator give zero for sin(PI)?

If you have an infinitely precise value for pi, then the sine of that value is indeed 0. But since the calculator is attempting to produce the value of a ten-digit (say) approximation of pi, the *correct* result should be the sine of that approximation.


Well, indeed, my TI and Casio calculators, the HP 48G as well as some PC programs produce sin(pi)=0. My HP 15c and HP 35s produce somevalueEE-13...

Edited: 13 Sept 2007, 9:10 a.m. after one or more responses were posted


But how many of them produce a non-integral result for int(PI)?


The ones that have an integer function yield an integer ;-)


Welcome back, Palmer!



There was a problem in the statistics routine such that if the user entered 4, 5, 6, 7, and 8 the mean would be displayed as 6 but the value in the machine was actually 6 - 1E-10 ! This was caused by use of a different algorithm for statistics accumulation where, for example, the sum of the input values was not stored, but rather the current mean and the number of entries was stored. V8N1P26-27 of TI PPC Notes).

I suspect that the running calculation of mean averages might have been intended to prevent possible errors in calculation of standard deviation of large values, due to roundoff errors of summation. For example, the HP models -- even the 12-digit Pioneer-series -- that calculate standard deviation from summation registers will return 0 as the sample standard deviation of [999,999 1,000,000 1,000,001]. The correct answer (1) will be returned by the models (e.g., HP-17B/BII, HP-27S) that retain all the entered data, then calculate standard deviation from the mean.

The TI-55II undoubtedly lacked the RAM to store all statistical input data.

-- KS


Hi, Palmer, thanks for the overview!


there are at least 3 ways to do this statistics job:

1. The calc stores all the input data.

2. The calc stores the necessary sums in the summation register.

3. The calc has to save memory and uses the approach Palmer sketched for the TI-55II.

Way 3 is the worst due to round off errors. Fully agree with you on this. I do not remember any calc using this way for decades. Extremely expensive memory was in the very starting years of scientific calcs only.

Way 2 is just fine if used with a tiny amount of thought. The fact that you run into problems with small deviations on top of big numbers is well known, and I have the feeling it was even mentioned in an early HP calc manual. Anyway, for sheer laziness, emmh economy, no reasonable person will key in 7 digits repeatedly where 2 are sufficient to do the job.

Way 1 replaces the missing brains of the user by additional memory in the calc. It became affordable when memory costs dropped.


The real advantage of Way 1 is that it allows the user to calculate residuals instead of only calculating correlation coefficients. That allows the user to identify individual bad data points and erroneously entered data points. Before there were hand calculators I used a program like that on a Honeywell time share network. My supervisor had a brand new shiny HP-45 and suggested that I could use it at my desk instead going to the terminal of the time share network. He showed me how to enter data and I tried to run a problem. When the results didn't look right I asked him how I could review the input data. He told me that I couldn't. That was the last time I used an HP-45 for statistics.

An example of the problems with Way 2 appeared in the article "Hard Wired Functions" in the March/April 1981 issue of PPX Exchange which was based on my submission. I had been exposed to the idea much earlier in a 1949 class in curve fitting by Professor Eggers at the University of Minnesota.

When I stumbled on the problem with the statistics routine in the TI-55II I had no idea as to what might be going on. I shared the observation with George Thomson who was one of the frequent contributors to TI PPC Notes. He immediately recognized the source of the problem and told me that the methodology was common back in the pre-war era.


Palmer, you are of course perfectly right.

I'd just not run a full fledge ANOVA on a pocket calc. Any stat data I use such a calc for are small amounts (let's say up to 30 points maximum), and I tend to look at the data before keying them in. For bigger data sets, nowadays PCs offer far better tools, starting with scatter diagrams ;)


I had always been under the impression that keeping a running mean and variance (or std dev) instead of the sums or was done for numerical stability. More arithmetic operations are required to use this approach (thus it is slower) but it isn't as prone to overflow and it doesn't require any additional storage.

A simple two point example where numbers are stored with two significant figures:

step    datum     ----- sigmaX -----  ------- mean ---------
2 sig digits true 2 sig digits true
1 10 10 10 10 10
2 0.8 11 10.8 5.5 5.4

I hope that is clear enough, I'm averaging two values 10 and 0.8 and showing the true values to infinite digits and the rounded versions.

By maintaining the mean instead of the sum we get:

step    datum   running mean
1 10 10
2 0.8 10 * (1 / 2) + 0.8 / 2 = 5.4

The update formula is:

        mn = mn-1 * ((n-1) / n) + xn / n

The overflow/loss of precision is avoided. A similar (more complicated) formula can be derived for the variance too.

I've been thinking about how to implement the usual statistics functions and am torn between the above approach and storing double or longer length internal summations...

- Pauli

Possibly Related Threads...
Thread Author Replies Views Last Post
  Digging for bugs Stefan Dröge (Germany) 2 175 11-13-2013, 04:39 PM
Last Post: Stefan Dröge (Germany)
  [HP-Prime] Simple Game (Bugs) CompSystems 1 183 11-01-2013, 10:18 AM
Last Post: Han
  HP-35s Cos[x] and Tan[x] bugs resolved? Thomas Windisch 2 201 10-31-2013, 01:12 PM
Last Post: Dieter
  RPN bugs both present in Prime Calc and emulator Eelco Rouw 9 433 10-16-2013, 12:22 PM
Last Post: Eelco Rouw
  [HP-Prime] AND, OR BUGs? CompSystems 0 102 10-04-2013, 04:03 PM
Last Post: CompSystems
  HP 50g: question about bugs Miguel Toro 2 207 09-26-2013, 01:27 PM
Last Post: Miguel Toro
  [HP-Prime xcas] operations with complex numbers + BUGs + Request CompSystems 9 471 09-08-2013, 10:40 PM
Last Post: CompSystems
  [HP_Prime] definition of functions, APPLY command and BUGs CompSystems 1 174 09-05-2013, 03:59 PM
Last Post: CompSystems
  [HP-Prime xCAS] Review Polynomial Tools + BUGs + Request CompSystems 0 138 09-05-2013, 12:53 PM
Last Post: CompSystems
  HP-Prime: Solution to ambiguity with [ ... ] & another BUGs CompSystems 12 481 08-28-2013, 08:48 AM
Last Post: CompSystems

Forum Jump: