HP 38G: Bug List Definitive - 4 Bugs in Total

[Gerald H]

Edit: To cut a long story short, here are the in total four bugs found:

1 Programme Editor

The top programme in the Programme Catalog is AA & a programme EDO appears lower down in the list of programmes.
You decide to make a new programme EDO in the New Program input form, which then asks "Replace existing program EDO?". On answering "YES" the text of AA appears. After deleting this text & entering the new programme, you will find EDO is now blank & AA contains the new programme.

2 Implicit Multiplication

The calculator enjoys the facility of implicit multiplication, eg KLM is accepted for K*L*M, 3M for 3*M.
Questionable behaviour occurs with SIN, interpreted as S*I*N & SIN(X), understood as sine function of X.
The bug appears on multiplying two conformable lists or matrices or complex numbers, eg M1*M2 is calculated correctly but M1M2 becomes M*1*M2, Z1Z2Z3 becomes Z*1*Z*2*Z3.

Of interest to followers of HP's history - These two bugs remain in the 40G & 40gs but NOT in the 39gii.

3 Arc-cotangent

Whatever the mode setting for "Angular Measure" may be (Degrees, Radians or Grads) the arc-cotangent function ACOT returns the angle in radians.

4 Sequence Aplet Numeric Big

In Sequence Aplet numeric view set "BIG" display mode. If you then scroll down one entry the value displayed in column k > 1 will be Uk(1).

On scrolling down further you will see correct values, with the error rising on the screen. After the error rolls of the top of the screen, 4 up scrolls will make the CORRECT sequence number appear.

The error appears after every recalculation, eg jump (not scroll) to the 1000th row & then scroll down discovers Uk(1).


There now follows the original thread for your interest:


Does the 38G have any actual bugs?

The calculator itself is a collection of inconveniencies, but I don't know of any actual bugs. It could easily be that most users were so put off by the machine that they never got as far as finding a bug.

I ask as I use the 38G in my classes (mostly for sequence questions) as I invested some years ago in a heap of that model.

Students find the 38G ugly & old-fashioned but are somewhat consoled that more elegant calculators, eg the Prime, have less capability (notably in sequence app) & tons of bugs.

I'd be pleased to put together a list of reported bugs.

[BruceH]

Colin Croft did a lot of excellent work with the 38G when it first came out. Unfortunately he doesn't have a bug list in one place so you have to look through his site.

You can cheat a bit by putting "site:www.hphomeview.com bug" into Google.

[Gerald H]

(03-16-2015 07:25 PM)BruceH Wrote:  Colin Croft did a lot of excellent work with the 38G when it first came out. Unfortunately he doesn't have a bug list in one place so you have to look through his site.

You can cheat a bit by putting "site:www.hphomeview.com bug" into Google.

In the FAQs referenced in the link I can not reproduce the behaviour in #22:

22. Is there a bug in the Sequence aplet?
Yes, as a matter of fact there is!
Let's see first how it's supposed to work:
In the Sequence aplet, enter 1 into U1(1), nothing into U1(2) and U1(N-1)+3 into U1(N). You should find that it ticks the U1(1) and U1(N) entries and that changing to the NUM view shows the correct sequence of 1, 4, 7...
SHIFT CLEAR to get rid of it.
Now enter nothing into U1(1) and U1(2). Enter 2^N into U1(N). Notice that when you enter a non iterative formula into U1(N) you don't need to supply the first and second values - it works them out for you.
SHIFT CLEAR again
Now the bug:
Enter 3 into U1(1) and U1(N-1)+2 into U1(N). What should happen is the same as the first example above. Instead, you will find that it calculates the value of U1(2). The problem is that it does it incorrectly! It does 3+2 and gets 4!!!!
It only happens (as far as I can discover) with those numbers. Don't ask me what made me try them - I do a LOT of testing of calculators for HP and you'd be amazed at the weird things I try in an effort to find bugs before the calculator is released. I've reported this to HP but it's so minor that I doubt it will be fixed. For those who are programmers, I seem to recall that the guru of the operating system told me that it was a pointer error.


My calculator sequence aplet will only tick if values are entered for the two initial terms.

Does anyone have a different experience?

[Gerald H]

Again, the FAQ 48 shows an oddity, but this does allow differentiating the product of S, I & N, ie SIN, from the function SIN().

I am reluctant to call this a bug.

48. Why does entering a function of X(X+2) give an error message?
Answer: Normally the calculator will realise when you are using an 'implied multiplication' such as '3X' meaning '3*X', but sometimes gets confused. You are probably already aware of the MATH button which contains a list of functions that can be used on the calculator. If so, then you must have noticed that each of them has to be used with brackets, like ROUND(3.23764,2) or SIN(35).

The problem is that when you write X(X+2) the calculator thinks that you are trying to use a function called X, rather than multiply by X, and tries to evaluate the function X at the point X+2 along the same lines as evaluating f(x+2). When it finds that there is no such function it puts up the error message shown. The solution is simply to remember to put in the multiplication sign.
Most people also run across this problem in the Solve alplet at some stage. For example, if you enter the equation S=A(1-R^N)/(1-R) in order to solve a geometric progression problem then you will find that you will only get error messages when you try to SOLVE in the NUM view. In this case you have to remember to specifically put a * between the A and the (1-R^N).


Opinions? & please be as critical/complacent as you are with the Prime.

[Gerald H]

This bug, although the author describres his model as a prototype, is present in my version A calculator:

Ein weiterer Fehler meines Rechnermodells tritt auf, wenn man ein älteres Programm überschreiben möchte. Gehen wir davon aus, daß seit dem Erstellen eines Programms XY ein weiteres neues Programm (oder mehrere) im Katalog PROGRAM aufgenommen wurden. Möchte man nun das ältere Programm XY überschreiben, so fragt der Taschenrechner nach, ob er das existierende Programm XY ersetzen soll. Bestätigt man diese Frage mit einem Ja ({{YES}}), so lädt mein Prototyp das im Katalog PROGRAM zuoberst stehende Programm in den Editor und nicht das zu ersetzende Programm XY. Eine Abhilfe ist hier leider nicht möglich. Man kann sich nur dadurch behelfen, daß man das alte Programm zuvor löscht und dann ein für den Taschenrechner neues Programm erstellt.

Interessanterweise wird aber bei diesem Überschreiben der Inhalt des zu ersetzenden Programms XY tatsächlich gelöscht. Lediglich der Aufruf des Editors geschieht mit dem falschen Programm.

From: Ralf Thoma, HP 38G Einführung in die Programmierung (1996), page 37.

[Gerald H]

The supposed bugs suggested by Colin Croft's FAQs I discard as being either not present in version A or merely unexpected behaviour.

Consequently the provisionally definitive bug list is:

From: Ralf Thoma, HP 38G Einführung in die Programmierung (1996), page 37:

An error appears if you try to overwrite an old programme. If the Program Catalog shows:

AB
CD

& you begin to write a new programme with the name CD you are asked "Replace existing program CD?" Answering "YES" the contents of the top of the list programme AB (rather than the expected text of CD) appear in the editor window. On deleting the text on the screen, writing the new text of CD & then closing the editor you find the contents of AB unchanged & CD contains the text you entered.

So the bug only(!) affects the screen display.

Making a grand total of one bug.

Edit: My result on performing Thoma's procedure is that AB contains the new text & CD is blank - Can someone please confirm the behaviour?

[Gerald H]

So here is the complete list of bugs in the HP 38G:

1 Programme Editor

The top programme in the Programme Catalog is AA & a programme EDO appears lower down in the list of programmes.
You decide to make a new programme EDO in the New Program input form, which then asks "Replace existing program EDO?". On answering "YES" the text of AA appears. After deleting this text & entering the new programme, you will find EDO is now blank & AA contains the new programme.

2 Implcit Multiplication

The calculator enjoys the facility of implicit multiplication, eg KLM is accepted for K*L*M, 3M for 3*M.
Questionable behaviour occurs with SIN, interpreted as S*I*N & SIN(X), understood as sine function of X.
The bug appears on multiplying two conformable lists or matrices or complex numbers, eg M1*M2 is calculated correctly but M1M2 becomes M*1*M2, Z1Z2Z3 becomes Z*1*Z*2*Z3.

Of interest to followers of HP's history - These two bugs remain in the 40G & 40gs but NOT in the 39gii.

[Han]

I don't think you'll find many bugs for this system for two reasons.

1) It was based off of the HP48 ROM which was already very mature, but many of the more complex features were removed from Alcuin/Hammer to make Elsie.

2) It seemed (to me anyway) that its user base was smaller and less of the hacking type (i.e. it didn't have the same level of programs being made for it, be it in the built-in language, in SysRPL/Applet, or in ML as compared to the HP48 series; those that exist were often ports from the HP48). So finding bugs would be less likely simply because there were/are fewer eyes capable of finding them.

[Gerald H]

(03-24-2015 03:06 PM)Han Wrote:  I don't think you'll find many bugs for this system for two reasons.

1) It was based off of the HP48 ROM which was already very mature, but many of the more complex features were removed from Alcuin/Hammer to make Elsie.

2) It seemed (to me anyway) that its user base was smaller and less of the hacking type (i.e. it didn't have the same level of programs being made for it, be it in the built-in language, in SysRPL/Applet, or in ML as compared to the HP48 series; those that exist were often ports from the HP48). So finding bugs would be less likely simply because there were/are fewer eyes capable of finding them.

I concur.

But it is strange that here, on this forum of all places, no one has contributed a single additional bug.

[Han]

(03-24-2015 03:11 PM)Gerald H Wrote:  

(03-24-2015 03:06 PM)Han Wrote:  I don't think you'll find many bugs for this system for two reasons.

1) It was based off of the HP48 ROM which was already very mature, but many of the more complex features were removed from Alcuin/Hammer to make Elsie.

2) It seemed (to me anyway) that its user base was smaller and less of the hacking type (i.e. it didn't have the same level of programs being made for it, be it in the built-in language, in SysRPL/Applet, or in ML as compared to the HP48 series; those that exist were often ports from the HP48). So finding bugs would be less likely simply because there were/are fewer eyes capable of finding them.

I concur.

But it is strange that here, on this forum of all places, no one has contributed a single additional bug.

I think it may be partly due to lower interest in this particular machine. I myself have one but it sits in its box untouched except for the one week I spent messing with it after purchase.

[Gerald H]

(03-24-2015 03:20 PM)Han Wrote:  

(03-24-2015 03:11 PM)Gerald H Wrote:  I concur.

But it is strange that here, on this forum of all places, no one has contributed a single additional bug.

I think it may be partly due to lower interest in this particular machine. I myself have one but it sits in its box untouched except for the one week I spent messing with it after purchase.

Yes, my opinion of the 38G is at least equally derogatory, viz my introduction in the initial thread.

I differ from you, I believe, in that I consider the Prime a new contender for a really bad calculator.

[Gerald H]

A third bug has appeared:

Whatever the mode setting for "Angular Measure" may be (Degrees, Radians or Grads) the arc-cotangent function ACOT returns the angle in radians.

[Marcus von Cube]

(03-30-2015 05:13 PM)Gerald H Wrote:  A third bug has appeared:

Whatever the mode setting for "Angular Measure" may be (Degrees, Radians or Grads) the arc-cotangent function ACOT returns the angle in radians.

The (emulated) 39gs does it right. So the bug must have been detected at one point.

[Gerald H]

(03-30-2015 07:18 PM)Marcus von Cube Wrote:  

(03-30-2015 05:13 PM)Gerald H Wrote:  A third bug has appeared:

Whatever the mode setting for "Angular Measure" may be (Degrees, Radians or Grads) the arc-cotangent function ACOT returns the angle in radians.

The (emulated) 39gs does it right. So the bug must have been detected at one point.

40G also does it correctly.

[Joe Horn]

(03-30-2015 05:13 PM)Gerald H Wrote:  A third bug has appeared:

Whatever the mode setting for "Angular Measure" may be (Degrees, Radians or Grads) the arc-cotangent function ACOT returns the angle in radians.

And yet another Prime bug appears: in CAS only, ACOT(0) always returns pi/2, even in Degree mode. (It correctly returns 90 in Home.) Firmware rev 6975.

[Gerald H]

(03-31-2015 09:05 AM)Joe Horn Wrote:  

(03-30-2015 05:13 PM)Gerald H Wrote:  A third bug has appeared:

Whatever the mode setting for "Angular Measure" may be (Degrees, Radians or Grads) the arc-cotangent function ACOT returns the angle in radians.

And yet another Prime bug appears: in CAS only, ACOT(0) always returns pi/2, even in Degree mode. (It correctly returns 90 in Home.) Firmware rev 6975.

Thank you.

The revenge of the 38G strikes yet again!

[Gerald H]

I add here the fourth bug so it finds it's chronological position:

In Sequence Aplet numeric view set "BIG" display mode. If you then scroll down one entry the value displayed in column k > 1 will be Uk(1).

On scrolling down further you will see correct values, with the error rising on the screen. After the error rolls of the top of the screen, 4 up scrolls will make the CORRECT sequence number appear.

The error appears after every recalculation, eg jump (not scroll) to the 1000th row & then scroll down discovers Uk(1).