HP39gII teaching materials online

[BruceH]

Chris Olley in the UK has produced some teaching materials for the HP39gII and has a copy of the manual available
on his website.

[Olivier De Smet]

I got mine this week, it is really a nice 'algebraic' calc.
You can even define real user function ie:

Lambert function

EXPORT w(y)

BEGIN

y -> Y; // you need to have all vars as global in solve expression

RETURN(SOLVE(X*e^X-Y,X,0,1));

END;

There are still some rought edges : determinant of integer matrice is not an integer :^)
I can't create a complex matrice either, but for real matrix, you can use this user defined function:

Matrix square root

EXPORT Matsqr(m)

BEGIN

  LOCAL a,b,c,d,l,t,n,o;

  SIZE(m)->l; IDENMAT(l(1))->b; m->a;

  FOR t FROM 1 to 20 DO

    .5*(b^-1+a)->c; .5*(a^-1+b)->d; // ^-1 is the uppercase -1 (aka 'new' 1/x)

    a-c->b; c->a; SPECNORM(b)->n; SPECNORM(a)->o;

    IF ((n/o) < 1E-7) THEN BREAK; END;

    IF (t==20) THEN 0*a->a; BREAK; END;

    d->b;

  END;

  RETURN(a);

END;

P.S. I have a "Ver: 09/May/2012 $Revision: 16633" model

- I got a lock at the logo display once when turning on, I have to press ON A F WHEN inserting a battery to recover (lost memory)

- I got a lock in the note editor too, I just have to remove all batteries to recover (no memory lost)

P.P.S I think this calc will get better and better when roms will be upgraded (I hope the connect software will be soon available)

Edited: 20 July 2012, 5:07 p.m. after one or more responses were posted

[Namir]

I ordered one from a Spanish online dealer (click here). I was glad he deduced the 18% VAT sales tax.

Namir

[Namir]

Olivier,

If I am correct, the single-letter variables need not be declared in a LOCAL statement. I use LOCAL to declare multiple-character variables.

Namir

[Tim Wessman]

If they are built in variables (A,B,C,...) then no, but since they are general variables and lowercase names they do need to be declared.

TW

[Namir]

Thanks Tim!!!

[Olivier De Smet]

It depend, as variables names are case sensitive, Y is a global variable by default and y can be declared as a local one.

If you don't declare variables in the second example, there is an error detected in the program when you 'check' it

Edited: 20 July 2012, 12:44 p.m.

[Gilles Carpentier]

Quote:

---

P.S. I have a "Ver: 09/May/2012 $Revision: 16633" model

---

I have the same..

I notice a curious thing .

WithON F4 (display version and system menu,the speed (top right) is in general 66MHz but sometimes 80 MhZ...

[Olivier De Smet]

I even got 22 MHz once

[Tim Wessman]

The speed displayed in there is an estimate only (using a known bit of ASM code that we can count the cycles). Since there is no way to actually get the speed of the processor at the moment, and the underlying operating system can switch away to do other things, that number really will fluctuate.

For example, plugging in another calculator will cause it to drop considerably as it does extra work to handle the USB-OTG communication stuff.

[Gilles Carpentier]

Just to compare the 'philosophy' of the 39GII and 50G,here is a version of MatSqr for the 50:

 «  EGV  « \v/ » MAP  OVER SIZE \->DIAG OVER INV 3. \->LIST \PILIST »

The advantage of the 50G are :

. 62Bytes (2,9KB for the 39GII)

. works in symbolic or approx (in symbolic an <<EVAL>> MAP at the end is interesting for a perfect result ):no rounding error and even parameters allowed

. RPN

Disadvantage

.Readibility (?) (but i find this more easy to write)

.What else ;)

It seems to me I saw an EIGENVV function in the 39GII. Perhaps this could simplify the 39GII program

Btw the39GII is very interesting. It is 20 x faster than the 50G. Imo the ROM have to be improve : my unit hangs twice when i tried to edit a program with alot of copy/paste.

Edited: 21 July 2012, 2:37 a.m.

[Tim Wessman]

The big culprit for size here is that everything is unicode based and your source code is kept intact as part of the program. The 50g userRPL code is actually compiled into pointers so that is all lost.

And yes, there will be continual improvements and more refinement and new features. One of the major points of creating a calculator from scratch was to make ongoing maintenance much easier.

TW

[Software49g]

> there will be continual improvements and more

> refinement and new features.

> to make ongoing maintenance much easier.

Nice joke, Tim.

Sounds familiar...



Regards,

Andreas

http://www.software49g.gmxhome.de

Edited: 21 July 2012, 4:52 a.m.

[Tim Wessman]

>Sounds familiar...

Let's see. You are right. It does sound familiar. I seem to remember back in 1999 when there was what was essentially a "new" calculator. I was around back then. Were you?

Called the 49g. I seem to remember, lets see... Yes! There were a lot of serious bugs at the start. And yes, there were a whole lot of roms released to address those issues and even - let me check - add new features and capabilities.

Amazing. Thank you for reminding everyone of how this works.

TW

Edited: 22 July 2012, 8:56 p.m.

[Software49g]

This was in no way meant as a personal attack towards you.

But everybody wears the shoes that ones fit.

And probably you are only allowed to do what your supervisor tells you.



> Were you?

You should know that very well.



> Called the 49g. I seem to remember, lets see...

> Yes! There were a lot of serious bugs at the start.

Yeah, most likely everybody remembers the "frozen hamster butt" and that it
took years to get a somewhat usable ROM. And the last one was even an
unsupported Beta ROM!

And then, without any communication to the customer, the company you work for
ditched the so favoured Flash ROM technology in simply stopping to make any
new updates available in favour of the 49G+.

And after a while the same is happening with the 50g, no updates for over
three years, which sounds to me like ringing the death-knell.



Should I continue with all the other products containing countless and
critical bugs, like the HP 35s, the HP 20b, the HP 15C LE, etc., etc.



Surely that improves credibility of the company you work for and convinces
customer to buy the products of the company you work for.



<irony>

Because surely it won’t happen again that the company you work for silently
rings the death-knell for another product, as this is something that the
great HP would never do.

</irony>





> Thank you for reminding everyone of how this works.

Thank you for confirmation that the company you work for still spits out
"banana products” that mature/ripen at the customer. Reminds that it was
right *not* to buy anymore products from that company.



But what else can one expect nowadays from HP?



And thanks for letting me know that critics and bug-reports are welcome...



Regards,

Andreas

http://www.software49g.gmxhome.de

[Gilles Carpentier]

In this precise case, the difference of size between the 2 versions is not signifiant because the 39GII program and 50G don't use the same algorithm.

I tried to use the 50G algorithm on the39GII :

EXPORT MatSqr(m)            // Input : m, a square matrix

BEGIN

  LOCAL l,d,s,i;

  l:=EIGENVV(m);            // return a list of 2 matrix 1/ Eigen vectors  2/Eigen values (the matrix completed with O not like on the 50G)

  d:=l(2);  s:=SIZE(d);     //We have to calculate the square root for each Eigen Value (on the diagonal)(a MAP command would be great to avoid explicits loops )

  FOR i FROM 1 TO s(1) DO   //For all elements of the diag of the matrix

     d(i,i):=SQRT(d(i,i));  //Square root : the symbol 

  END

  RETURN l(1)*d*l(1)^-1;    // result is P*d*P^-1 (char for 1/x on the 39GII): A square root of the input matrix

 END;

Works fine... 1,6kb

It seems that you cannot enter a matrix in input of a function with the debugger ?! -> Entrée invalide
btw the debugger seems very interesting

Note that the 50G program seems to work also like this
EGV « \v/ » MAP OVER SIZE \->DIAG OVER INV * *

For complete comparaison, if EGV will have work the same way as EIGENVVon the 39GII, it would be only :
EGV « \v/ » MAP OVER INV * *

Edited: 21 July 2012, 1:00 p.m.

[Tim Wessman]

Note you can also run the debugger from the home screen by surrounding your program call with 'debug( )' and pressing ENTER. It is just the pop up dialog from the catalog that has issues there.

Glad you like the debugger! For those that have not seen it, it lists the contents of you global/local variables as they change, and you can even browse any other system variables as you debug. In essence, it behaves much more like a modern IDE debugging environment.

Does your 1.6kb include those comments? Or were those just added for this post?

Will try to get MAP or similar added.

Quick poll: is MAP the normal name for this type of command in other math programs/packages? Anything that is more common or universal?

TW

Edited: 21 July 2012, 11:22 p.m.

[Gilles Carpentier]

Hi Tim,

The size is without the comments...

I think MAP is the 'normal' name (Mathematica and many other languages). Imo MAP should apply to matrix, lists and vectors,like on the 50G

1/ With matrix,no problem :

MAP( Function(x), M1)
It is like on the 50G
M1 << NEXTPRIME >> MAP

It would be fine if we could use an algebraic expression for the 'function' without defining it before( but then how to manage parameters ?)
MAP ( -> x '2*x^2+2*x+7', M1)

2/ With list

On the 50G MAP applies the program to all the items ( include inner lists).( but we can use DOLIST for more complex things)

I think it would be judicious to have an additionnal argument for the "level of deep" to manage inner lists (i dont like very much the idea of variable number of arguments for a function but it's already that way on the 39GII and it has his advantages)

So we could manage in different ways :

{ 1 2 3 4 }

{ {1 2} {3 4} }

{ { 12 3 4} {1 { 2 5}}}

0 : compute all the items (inner lists include)- default value

1 : compute only the first level of the list

2 : compute first and second level

n : compute 1..n level

MAP (-> x 'SORT(x)', L1, 1) will sort all the first level inner list of L1

MAP ( -> x 'IF x==0 THEN x:=1E-499 END', L1)

Here are some implementaion of MAP in various language :

Map examples

PS : also note that in the 50G, in many occasion there is no need of MAP command and the // list processing is very powerfull

{ 2 3 4 } 1 - gives { 1 2 3 }

{'a' 'b' 'c' } SIN gives { 'SIN(a)' 'SIN(b)' 'SIN(c)'}

{2 3 4 } { 1 2 3 } - gives { 1 1 1 }

{2 3 4 } 2 * gives { 4 6 8 }

{2 3 4 } { 1 2 3 } - gives { 2 6 12 }

etc. (AppendixC AUR)

In that point of view the APLY program example in the AUR is a non sense

Edited: 22 July 2012, 6:27 a.m.

[Oliver Unter Ecker]

MAP, EACH, FOREACH.

Is the language dynamic enough to have the concept of functions as data? That is, can you do something with, say, SQRT, other than calling it?

IMO, better than MAP is doing mapping automatically. That is, instead of telling the user "hey, you can't apply SQRT to a vector", apply the function component-wise.

ND1 does that in interactive operation and in RPL. For example: << [9 -1 '3+x' ] sqrt >> becomes [3 (0,1) 'sqrt(3+x)']

[Gilles Carpentier]

I

[Gilles Carpentier]

Quote:

---

IMO, better than MAP is doing mapping automatically.

---

Hi Oliver,

I agree with the general idea. On the 50G it works like this for lists.

{ 4 9 16 } SQRT -> { 2 3 4}

but sometimes it is not possible...

For example,take the square root of a matrix... What do you do with this ? .... Like with a list,or with the mathematical definition of a square root matrix M=M'*M'so Sqrt(M)-> M'

I cannot use ND1 because I have no iPhone/iPad but I remenber you work with lists in the same ways than matrix.In most cases it's OK but not every time.

I think that it is important to have a global view about list processing to be coherent. For example, on the 50G (due to the legacy of the 48 and backward compatibility), there is confusion about + and ADD commnd.

The 39GII is developped from scratch and it is important to avoid this, and to have a global idea on how to do with list processing.

command such as FILTER ,MAP, ZIP are very powerfull.
I use a lot this library for the 50

GoferList

Edited: 22 July 2012, 3:53 p.m.

[Oliver Unter Ecker]

Hi Gilles,

Just to clarify: I'm suggesting it's a good idea to use automatic element processing in those cases where a calc would normally throw a "wrong type of argument" error involving lists/arrays/vectors/matrices. As such, automatic processing wouldn't be in the way of type-specific definitions. For example, SQRT could still be defined to operate on a matrix and have the behavior as discussed above. (Nice code, by the way.)

Yes, you're picking the exact right example for when there's trouble with a united list/array approach: you cannot really have the "+" operator both ways. (ND1 has append and concat functions to deal with the ambiguity.)

And, yes, I agree with you that when doing something from scratch is the best time to get things like that right. And that list (or, rather, array) processing is very cool. (Esp. on a calculator, where you want to minimize the character count to write programs.)

Something like

<< cmdA cmdB cmdC >>

where each cmdXXX performs array processing, makes for super-short yet capable programs that operate on arrays (*and* scalars!). The syntax couldn't be simpler to write and read, and really leverages RPL's invisible transport of inputs and outputs and type inference--two great features (rarely found elsewhere).

Compare this to

syntax to declare program

assign input to some local

for (i from 1 to size(input))

BEGIN

    somelocal[i] = cmdA[input[i]]

END

for (i from 1 to size(input))

BEGIN

    somelocal[i] = cmdB[somelocal[i]]

END

for (i from 1 to size(input))

BEGIN

    somelocal[i] = cmdC[somelocal[i]]

END

return somelocal

which does the same.

With capable commands, you can also do auto-processing with algebraic notation, of course. Something like this, for example:

BEGIN RETURN cmdC(cmdB(cmd(INPUT))) END

To me

<< DIVIS SQ TOTAL >>

sure looks better than

<< =input TOTAL(SQ(DIVIS(input))) >>

[Gilles Carpentier]

Quote:

---

To me

<< DIVIS SQ TOTAL >>

sure looks better than

<< =input TOTAL(SQ(DIVIS(input))) >>

---

:D

To me too

In my mind,RPL is like words manipulating objects... Not magic spells but sometimes... ;) It's difficult do explain but i dont think the same way when I want to solve a problem in RPL than with an algebraic language. RPL is near what you do to solve the problem in an interactive (english word ?) approch unlike many other language.

Edited: 23 July 2012, 6:17 p.m.

[Oliver Unter Ecker]

Tim & whoever else has been involved at HP in creating the 39gII: Kudos and congrats!

I combed through the manual and am impressed. The scope of what this machine can do is quite a bit greater than I had imagined. You guys did a great job and this seems a very fine calc indeed!

From this group of spectators and speculators, it often sounded like the calculator group was mainly in maintenance mode, but this product shows you guys have been very much in creation mode. Splendid.

Hope it will meet deserved success in the marketplace!

Edited: 22 July 2012, 12:27 p.m.

[Charles C(UK)]

My 39GII has hung up a couple of times, mostly when or after I have been connecting to a PC via USB. Taking the batteries out was the only answer, since no hardware reset - a good project for a skilled forum member to have a try at.

I think the emulator ROM version is later than the one shipped on my calculator (09 May 2012, Rev 16633). It has the jump to letter of the alphabet feature in the 259 item catalog, whereas on my machine you have to scroll through the whole lot to get the command you want.

Edited: 21 July 2012, 9:00 a.m.

[Tim Wessman]

There actually is a hardware reset. It's just not labeled as such.

There is ON-F3. If that doesn't work, you can stick something down the hold in the left middle of the battery compartment and it will disconnect the power.

Personally, I find it easier to pop the batteries. Always have on the 50g as well.

TW

[Charles C(UK)]

I see no hole and don't remember any visible means of physically interrupting the power when I had the back of the calc. As I remember, the leads from the battery compartment terminals ran directly to the PCB. Maybe this feature was was present on pre-release test units in circulation at HP.

Could you post a picture to clarify?

Thank you.

[BruceH]

If you find you are having to reset a lot then you can always power it over USB and run without any batteries. Then it is as quick as pulling the cable.

[Olivier De Smet]

I got some strange behaviour and a hung playing with 'solve app'

set FIX 4

enter 'X^X-Y=0' as E1 go to 'Num' view

enter 512 in Y

solve for X get 4.28627605527

edit X as       4.28627605528

solve for Y get 512.030103613 ??

solve for X get 4.2863 (X was rounded but not displayed as rounded)

now set STD

do the same : 

enter 512 in Y

solve for X get 4.28627605527

edit X as       4.28627605528

solve for Y get 512.000000001

enter 512 as Y

solve for X get 4.28627605527204 nice 15 figures real number :)

I got the same behaviour with 16633 and last emulator ...

Eventually I got a hung when entering a number -> remove the battery

Edited: 22 July 2012, 5:12 a.m.

[Tim Wessman]

Thanks. Will investigate.

TW