The Museum of HP Calculators

HP Forum Archive 21

[ Return to Index | Top of Index ]

HP 39 GII
Message #1 Posted by Bunuel66 on 5 July 2012, 6:10 p.m.

Just for information. The HP 39 GII is now starting to be available in France. Not yet widely spread in shops, but first models are delivered.

Stay tuned ;-)

      
Re: HP 39 GII
Message #2 Posted by Matt Agajanian on 5 July 2012, 11:29 p.m.,
in response to message #1 by Bunuel66

Thanks! This explains why I haven't seen it in the US store yet, even though there was a post here about its pre-release stage a few months ago.

            
Re: HP 39 GII
Message #3 Posted by Namir on 6 July 2012, 12:36 a.m.,
in response to message #2 by Matt Agajanian

I look forward to seeing the 39gII on the US market. It is really a nice machine and is able to support good programming. The Basic-like language is very easy to read.

Namir

                  
Re: HP 39 GII
Message #4 Posted by Mike Morrow on 6 July 2012, 8:58 a.m.,
in response to message #3 by Namir

Quote:
...is able to support good programming. The Basic-like language...

But...does it allow the most evil programming construct of all time (according to believers in the Religion of Structured Programming), the GO TO statement? :-)

                        
Re: HP 39 GII
Message #5 Posted by Tim Wessman on 6 July 2012, 9:08 a.m.,
in response to message #4 by Mike Morrow

No GOTO.

You do have the ability to do things like BREAK 2; and similar to break out of two nested loops. That really is the only valid use for GOTO both cyrille and I have ever discovered. Well, that and a state machine potentially.

                              
Goto and Jump
Message #6 Posted by gene wright on 6 July 2012, 10:14 a.m.,
in response to message #5 by Tim Wessman

I understand the "evil" nature of user code GOTO constructs, having taught structured programming in the past (as well as a CS undergraduate degree).

However, I have often found it ironic in the extreme that structured user code gets translated into JMP and Branch instructions in machine language.

At least, it did when I was programming PDP/11 code. ;-)

                                    
Re: Goto and Jump
Message #7 Posted by Rory Molinari (USA) on 6 July 2012, 10:33 a.m.,
in response to message #6 by gene wright

GOTO is bad because it can lead to code that is hard for people to read, and thus that is hard to maintain and modify.

Computers are happy to execute any old nonsense they are asked to. If the translation to machine code is correct it could even use something like INTERCAL's COMEFROM instruction and no-one would be any the wiser.

                                          
Re: Goto and Jump
Message #8 Posted by Mike Morrow on 6 July 2012, 11:27 a.m.,
in response to message #7 by Rory Molinari (USA)

Quote:
Computers are happy to execute any old nonsense they are asked to.

Still...there's no reason that higher level languages must or should prohibit the simple GO TO if that's what the individual programmer wants...individual like...er...a calculator owner. Its existence would not make structured programming the least bit more difficult...if that's what the programmer wants. We don't need corporate or academic tyranny at this level! That's a giant part of the reason RPL failed as a quick and easy tool for the types of problems a calculator user needs to solve.

But...I know...it's a religious issue and thus is not subject to any counter argument.

                                          
Re: Goto and Jump
Message #9 Posted by Mark Storkamp on 6 July 2012, 12:01 p.m.,
in response to message #7 by Rory Molinari (USA)

Quote:
GOTO is bad because it can lead to code that is hard for people to read, and thus that is hard to maintain and modify.

I can't remember the last time I saw someone make up a flow chart or state diagram for their program (myself included). I think the real reason for code being hard to maintain is the lack of documentation. It's just easier to blame GOTO or lack of OOP.

Yes, there are zealots who would ban anything that doesn't strictly conform to 'Structured Programming', but I'll take any advantage I can. For me there can't be enough tools.

                                                
Re: Goto and Jump
Message #10 Posted by HAL9000 on 6 July 2012, 1:01 p.m.,
in response to message #9 by Mark Storkamp

I learned programming in FORTRAN IV and using flow charts. I still draw flow charts and I like the GOTO. I guess you can call me an old timer.

Edited: 6 July 2012, 2:13 p.m. after one or more responses were posted

                                                      
Re: Goto and Jump
Message #11 Posted by Eddie W. Shore on 6 July 2012, 1:21 p.m.,
in response to message #10 by HAL9000

Quote:
I learned programming in FORTRAN IV and using flow charts. I still draw flow charts and I like the GOTO. I guess you can call me and old timer.

I am not religious, therefore GOTO is not evil!

Seriously, I don't get all the animosity towards GOTO. I will use that statement if it helps me accomplish my task.

                                                      
Re: Goto and Jump
Message #12 Posted by Les Koller on 13 July 2012, 6:21 p.m.,
in response to message #10 by HAL9000

I learned programming in the early 80's with COBOL, FORTRAN, and PL/1. Nowadays if I need a really quick or dirty estimate, I'll use JustBasic. It's a nice basic with mutli-digit precision. I often find myself reasoning out a do while or do until, not wanting to violate the GOTO rule, and after just a few seconds I say "Screw it. It's just for me!" and use GOTO liberally.

I can do without it...I write JAVA, Ruby, Python, and a little LUA too, but if I'm writing BASIC, I'm gonna use it!

Edited: 13 July 2012, 6:22 p.m.

                                    
Re: Goto and Jump
Message #13 Posted by Thomas Radtke on 6 July 2012, 11:35 a.m.,
in response to message #6 by gene wright

Quote:
However, I have often found it ironic in the extreme that structured user code gets translated into JMP and Branch instructions in machine language.
A higher language should imho focus on readability, while this doesn't matter in compiled code. And about relative and absolute jumps, which CPU offers you other options? ;-).
                                    
Re: Goto and Jump
Message #14 Posted by Gilles Carpentier on 6 July 2012, 2:20 p.m.,
in response to message #6 by gene wright

No GOTO in the 39II, but you can use :

BREAK
CONTINUE
CASE
etc.

I like the possibility of LOCAL variables or functions in a more easy way than in UserRPL

Edited: 6 July 2012, 2:22 p.m.

                                          
Re: Goto and Jump
Message #15 Posted by cyrille de brebisson on 6 July 2012, 3:07 p.m.,
in response to message #14 by Gilles Carpentier

Hello,

more interestingly, you can use BREAK x; and CONTINUE x; which lacks in most higher level languages:

ie: while cond do begin for A=0 to 5 do begin if SomeCondition then EXIT 2; end; end;

Which, to my limited knowledge only exists in 2 syntaxes: MASD (the HP50g Assembly compiler) and the HP39GII language.

cyrille

                                                
Re: Goto and Jump
Message #16 Posted by Gilles Carpentier on 6 July 2012, 3:19 p.m.,
in response to message #15 by cyrille de brebisson

interesting improvement !

This is not explained neither in the user guide nor in the "39GII Help"

The lacks of BREAK and CONTINUE is problematic in HP50. We can do without of course, but it is far better with :)

                                                
Re: Goto and Jump
Message #17 Posted by Patrice on 6 July 2012, 4:48 p.m.,
in response to message #15 by cyrille de brebisson

Bonjour Cyrille,

Any other nuggets that are not in the manual ? Where can I find them?

Patrice

                                                
Re: Goto and Jump
Message #18 Posted by Pete Wilson on 6 July 2012, 6:25 p.m.,
in response to message #15 by cyrille de brebisson

BASH supports exactly the same kind of break and continue statements and Java and Perl supports named breaks :)

                                                
Re: Goto and Jump
Message #19 Posted by x34 on 6 July 2012, 6:41 p.m.,
in response to message #15 by cyrille de brebisson

The language closely resembles Modula-2 by N. Wirth. I like it. Would like the new OS to be ported to HP-50g.

Edited: 6 July 2012, 6:53 p.m.

                              
Re: HP 39 GII
Message #20 Posted by fhub on 6 July 2012, 10:22 a.m.,
in response to message #5 by Tim Wessman

Hi Tim,

any idea when the emulator will be finished? ;-)

Regards,
Franz

                        
Re: HP 39 GII
Message #21 Posted by Matt Agajanian on 6 July 2012, 12:34 p.m.,
in response to message #4 by Mike Morrow

Hi there. This brings up a very intriguing conundrum. Since 'go to' is so evil, how was it tolerated on models ever since the HP-65?

                              
Re: HP 39 GII
Message #22 Posted by JimHorn on 6 July 2012, 5:18 p.m.,
in response to message #21 by Matt Agajanian

Well, Matt, the trick on the HP-65 was to make a programmable calculator *at all* so many simplifications were needed - key codes, numeric-only display, very limited memory, limited subroutines, etc. As time went by, the limitations were slowly eliminated but the compromises they engendered took longer to fade away due to reverse compatibility.

GOTO is *not* intrinsially evil but lends itself to unclear thinking producing unclear source code resulting in fertile breeding grounds for flaws (i.e. "bugs"). As noted, almost all CPU architectures end up with their machine level code only knowing GOTOs (relative and absolute) and GOSUBs. But then again, few of us still code in binary, yes?

With calculator memory and CPUs running many orders of magnitude faster and larger than we dreamed of in the 1970s, it is no surprise that the user code interface has changed as well.

Jim (face down, nine edge first)

                                    
Re: HP 39 GII
Message #23 Posted by Matt Agajanian on 6 July 2012, 6:33 p.m.,
in response to message #22 by JimHorn

You're right. Just because a function is there doesn't mean it must be used. But, it's a two-fold tool. Go To does lead to some very clever and ingenious programming. On the flip side, it does make careless and undisciplined programming possible. Although, like I said, just because it's there doesn't mean it's absolutely necessary.

                                          
Re: HP 39 GII
Message #24 Posted by Thomas Radtke on 7 July 2012, 2:48 a.m.,
in response to message #23 by Matt Agajanian

Quote:
Go To does lead to some very clever and ingenious programming.
Examples? Other than obfuscating the code? ;-)

I program in C since 1986 and was never in need of goto, nor can I imagine where goto would have led to something clever or ingenious.

If I must twist my brain for peephole optimizing, I'd rather use Assembler.

                                                
Re: HP 39 GII
Message #25 Posted by Matt Agajanian on 9 July 2012, 8:24 p.m.,
in response to message #24 by Thomas Radtke

Hi there.

I've found Peter Henrici's book 'Computational Analysis On the HP-25 Pocket Calculator' to be a very supportive and beneficial case for GTO. Although yes, when GTO is all you've got (e.g. Novus Mathematician PR and Scientist PR models and several Casio LED ones in the day with their JMP key), looking at how to use GTO effectively from the mindset that Peter's book illustrates, GTO can be quite beneficial.

And yes, if a later model such as an HP-33E/C, HP-11C, SR-56, TI-58C is available where a GSB or SBR key is featured then yes, divorce from the GTO option in all cases.

Edited: 9 July 2012, 8:26 p.m.

                                    
Re: HP 39 GII
Message #26 Posted by Gilles Carpentier on 6 July 2012, 6:46 p.m.,
in response to message #22 by JimHorn

Perhaps I'm wrong but it seems to me that it's a very bad idea to mix GOTOs and structures like REPEAT UNTIL, CASE, DO LOOP, START NEXT etc... and obviously with procedures or functions. Not because it's not very readable (or any religious idea ;) but because the compilator (or interpreter) could be in trouble with such things (mixing structured and unstructured). The compilator (or interpreter) must know if he is inside or outside a structure, manage his internals stacks, frees internal counters ...

The problem is not the GOTO , but is the mix of GOTO and structured formalisms... If you want GOTO then forget more sophisticated structures, or limit the usage of GOTO in such a way that the GOTO loses his interest.

For example, exit of a loop in Basic with a GOTO is a very bad idea because the BASIC (compiler or interpreter) could lose some informations or have problem with internal stacks. Idem a GOTO to a GOSUB structure will cause a problem at the RETURN point (in assembler you can perhaps play with some pop or push on the stacks, but in a high level langage you can't) . In a more 'rustic' language, it can be done because there is less (or no) 'hidden' operation (stacks, temporay variable...)

On my old Casio FX602P

100 Min00 .9 MinF 
LBL0
  RAN# x>F GOTO9
DSZ GOTO0
LBL9
MR00 HLT

is not a problem. I exactly understand what happens.

But in basic :

FOR A=100 TO 1 STEP -1
 IF RANDOM > 0.9 THEN GOTO 10
NEXT A
10 PRINT A
is unclear... Does the computer understood he jumps outside the FOR NEXT structure or not ? How the computer manages internaly this loop ? Does it search back when he found a NEXT to the previous FOR ? Or is the address of the FOR in a temporary stack to improve the speed when he he is at the "NEXT" point (and if so, what happens for this data if we exit the loop with a brutal GOTO ?). GOTO into imbricated IF/THEN/ELSE are unclear also etc.

Just my 2 cents (of euro of course) ;)

Edited: 6 July 2012, 7:33 p.m.

                                          
Re: HP 39 GII
Message #27 Posted by George Litauszky on 7 July 2012, 5:52 p.m.,
in response to message #26 by Gilles Carpentier

Quote:
The problem is not the GOTO , but is the mix of GOTO and structured formalisms...

For example:

 1 LET A=101
 2 LET A=A-1
 3 IF RANDOM > 0.9 THEN GOTO 10
 4 IF A >= 2 THEN GOTO 2
10 PRINT A

Or:

FOR A=100 TO 1 STEP -1
 IF RANDOM > 0.9 THEN EXIT
NEXT A
PRINT A

Edited: 7 July 2012, 6:41 p.m.

                                          
Re: HP 39 GII
Message #28 Posted by Marcus von Cube, Germany on 8 July 2012, 7:38 a.m.,
in response to message #26 by Gilles Carpentier

That's what I like in languages like C or Java: The control structures are what I would call "explicit". There is no hidden code or data while a for(;;) loop is active, so leaving it is totally safe.

                                    
Re: HP 39 GII
Message #29 Posted by Guenter Schink on 7 July 2012, 5:38 a.m.,
in response to message #22 by JimHorn

Quote:
GOTO is *not* intrinsially evil but lends itself to unclear thinking producing unclear source code resulting in fertile breeding grounds for flaws (i.e. "bugs"). As noted, almost all CPU architectures end up with their machine level code only knowing GOTOs (relative and absolute) and GOSUBs. But then again, few of us still code in binary, yes?

Back in 1983 when I learned to program a mainframe (Siemens BS200) in assembler. One of the most important things, a dogma, was to strictly adhere to structured coding. Each snippet of code had to have a clearly defined entry and exit. We had to follow the principles for structured programming set by Michael A. Jackson.

Funny enough, on a test two of my mates made a strange experience on a test. The code of A produced the correct result but was rated unsatisfactorily. The code of B failed on the problem, but was rated being reasonable .

Reason was: A's code was such a "spaghetti" it was almost impossible to determine in reasonable time, why it worked at all. B's code was so well structured, that the minor glitch could be seen in very short time.

Günter

                  
Re: HP 39 GII
Message #30 Posted by Cristian Arezzini on 6 July 2012, 11:13 a.m.,
in response to message #3 by Namir

Quote:
I look forward to seeing the 39gII on the US market. It is really a nice machine and is able to support good programming. The Basic-like language is very easy to read.

Namir


Is there a manual we can download? I would like to know if there are easy ways to access the display directly with graphic commands (i.e. PIXON, LINE and such)...

CRistian

                        
Re: HP 39 GII
Message #31 Posted by fhub on 6 July 2012, 11:33 a.m.,
in response to message #30 by Cristian Arezzini

Quote:
Is there a manual we can download?
Here are even a few of them: :-)

http://www.hpgraphingcalc.org/hp39gii.html

Franz

                              
Re: HP 39 GII
Message #32 Posted by Tim Wessman on 6 July 2012, 2:34 p.m.,
in response to message #31 by fhub

That is a fun page I have not seen before.

The manual on it is quite old, but I believe it would have the info on the graphic commands.

Basically, there are two versions of each command. Ones uses your current window position settings in your plot view and takes real numbers. The _P version is pixel based where 0,0 is the upper left corner. They all function similar to this:

LINE and LINE_P

Syntax: LINE([G], x1, y1, x2, y2, [c]) LINE_P([G], x1, y1, x2, y2, [c])

Draws a line of color c on G between points x1,y1 and x2,y2. G can be any of the graphic variables and is optional. The default is G0. c can be 0 to 3 (0=black, 1= dark gray, 2= light gray, 3= white). c is optional. The default is black.

                                    
Re: HP 39 GII
Message #33 Posted by fhub on 6 July 2012, 3:09 p.m.,
in response to message #32 by Tim Wessman

Quote:
That is a fun page I have not seen before.

The manual on it is quite old ...


Well, the Quickstart Guide is from 05/2012, so I won't really call it 'old'. ;-)

The Users Guide is from 12/2011, so this may indeed be 'old' in our fast moving time. Is there already a newer version available?

And what about the emulator, is it already finished or still under development?

Franz

                  
Re: HP 39 GII
Message #34 Posted by Eddie W. Shore on 6 July 2012, 12:49 p.m.,
in response to message #3 by Namir

Quote:
I look forward to seeing the 39gII on the US market. It is really a nice machine and is able to support good programming. The Basic-like language is very easy to read.

Namir


Agree, maybe it will be here in the US in time for Back to School. We can only hope.

                        
Re: HP 39 GII
Message #35 Posted by Matt Agajanian on 6 July 2012, 1:36 p.m.,
in response to message #34 by Eddie W. Shore

I'd like to add the 39gII as well. It seems a pleasant unit, much more functionality and enhanced UI than the 38G and refitted with a streamlined programming language. Seems like this one will be a joy to play with.

Edited: 6 July 2012, 1:37 p.m.

      
Re: HP 39 GII
Message #36 Posted by Gilles Carpentier on 6 July 2012, 2:05 p.m.,
in response to message #1 by Bunuel66

Hi, I've just received my 39GII :D (in France)

It is a very interesting calculator. My reference is the 48/50 serie and I never use the 39GS. My first impressions :

- The calculator is very easy to use with the Apps concept - It is very fast - I like the program editor - I like the programmation language

About the speed :

EXPORT Test(N)
BEGIN
 R:=0;
 FOR I FROM 1 TO N DO
  R:=R+I;
 END;
 R
END;
Test(10000) takes 1 second (31 second with a 50G)

A simple loop :

EXPORT Test
BEGIN
 FOR I FROM 1 TO 10000 DO END;
END;
takes about no time. 1 to 100000 takes 4 sec (250s. with a 48GX)

The "context help" is well done (and in french if you want ;)

I use it in small font and " , " for decimal separator. It's fine for use in good light condition. But in my opinion, i would have prefered a bolder font to improve readibility. (and perhaps a "very small font" option ;)

I noticed that in small font, numbers like ,33 appears as 0,33 wich is a good point to improve readibility

No time now, but i will do more tests next week

Edited: 6 July 2012, 2:42 p.m.

      
HP 39 GII
Message #37 Posted by Bunuel66 on 11 July 2012, 7:51 a.m.,
in response to message #1 by Bunuel66

Just got my HP39 GII today (southern France). Received without any packaging. I'm traveling for business up to the end of week. I keep the calculator with me. Hope to post some feelings when I'll be back.

Regards

            
Re: HP 39 GII
Message #38 Posted by Charles C(UK) on 13 July 2012, 6:58 a.m.,
in response to message #37 by Bunuel66

I received my HP39GII on Tuesday. The street price in the UK seems to be 55 to 65 GBP delivered,which should frighten Texas into being more realistic on the UK pricing of some of their aged products. I couldn't find a UK supplier by searching HP39GII but the HP product code, NW249AA, brought up plenty.

My experience with the calculator has been mixed. It ran nicely for five minutes then turned itself off. I noticed one battery was quite warm and then a few moments later a thread of smoke appeared from the battery compartment accompanied by a fritzing sound. I thought that would be curtains for the calculator but it came back up and worked great when I inserted fresh batteries. HP responded very quickly to my tech support e-mail and half convinced me that it was an internal short on one of the batteries.

Naturally, curiosity got the better of me, so kissing goodbye to my warranty I opened the thing up. There are six screws to undo (two hidden under a full width rubber anti slip bumper). The white fascia is retained to the casing by very shallow lugs, which release easily when the case sides are gently coaxed with a penknife blade.

I expected to find something burned inside but there was nothing to see. I did find a whisker of solder leading out from the positive power connection pad on the chassis. My best guess is that this was shorting the battery pack but was blown out when the smoke showed.

With the negatives out of the way, I have to say this is a nice unit. The case is very solid, the keys just right and the display is beautiful and crisp. It runs like a rocket and its functionality is a model of clarity. Plus, it is easy to take apart if you need to!

An RPN HP50GII based on this hardware would be a must have.

End note: along the way, I discovered that the diagnostics menu can be invoked by powering up with F4 depressed.

                  
It's not a bug it's a feature
Message #39 Posted by Bunuel66 on 13 July 2012, 3:45 p.m.,
in response to message #38 by Charles C(UK)

Just playing with my 39 GII I have observed that e^(0+i*pi) doesn't provide the same result as EXP(0+i*pi). The first expression delivers a totally wrong result, while the second one gives a better result... Despite being said in the user guide that e and EXP use not exactly the same algorithm it seems a bit confusing and a real risk for missing an error within a computation using complex numbers.

Anyone has got the same or a similar annoyance...?

Regards

                        
Re: It's not a bug it's a feature
Message #40 Posted by fhub on 14 July 2012, 7:52 a.m.,
in response to message #39 by Bunuel66

Quote:
Anyone has got the same or a similar annoyance...?
Yes, I can confirm it on the 39gII emulator: both give -1 as real part and ...E-12 or ...E-13 as imaginary part.

But I guess the problem is even deeper. I don't know how the internal representation of complex numbers is implemented in the 39gII, but not even a simple i^2 gives exactly -1, the returned result is -1-6.76...E-15*i ???

Well, that's not what I expect from a highend HP calculator! :-(

Franz

                              
Re: It's not a bug it's a feature
Message #41 Posted by Gilles Carpentier on 14 July 2012, 5:27 p.m.,
in response to message #40 by fhub

Hi,

On my unit both i² and i*i give exactly -1+0*i

It seems there are several versions of ROM in circulation...

                                    
Re: It's not a bug it's a feature
Message #42 Posted by Mike Morrow on 15 July 2012, 12:18 a.m.,
in response to message #41 by Gilles Carpentier

Quote:
It seems there are several versions of ROM in circulation...

Is the firmware of the 39gii easily updated in a manner similar to the HP49G/50G series?

                                          
Re: It's not a bug it's a feature
Message #43 Posted by Gilles Carpentier on 15 July 2012, 3:23 a.m.,
in response to message #42 by Mike Morrow

I hope so beacause there is an option for that when you type "ON-F4"

You can see the version , mine is

Ver 09/May/2012 $Revision 16633 $ 80MHz

(I notice that the MHz sometime change between 66 and 80 Mhz (?)

Option 9 is "Start Update". Others are about tests, PC_Link, Unit_To_Unit link ...

                                    
Re: It's not a bug it's a feature
Message #44 Posted by fhub on 15 July 2012, 5:19 a.m.,
in response to message #41 by Gilles Carpentier

Quote:
On my unit both i² and i*i give exactly -1+0*i

It seems there are several versions of ROM in circulation...


Oh, it was my fault - I didn't use the x² button but calculated i² with y^x.

Nevertheless I would say that for an integer exponent 2 the operation y^x should give the same result as x².

                              
Re: It's not a bug it's a feature
Message #45 Posted by Cristian Arezzini on 15 July 2012, 3:21 a.m.,
in response to message #40 by fhub

Franz, where did you find the emulator? I looked around but couldn't find it...

                                    
Re: It's not a bug it's a feature
Message #46 Posted by fhub on 15 July 2012, 5:13 a.m.,
in response to message #45 by Cristian Arezzini

Quote:
Franz, where did you find the emulator? I looked around but couldn't find it...
Hi Cristian,

it is available on the website of an official Swiss HP dealer:
http://www.hp4calc.ch/index.php?option=com_content&view=category&layout=blog&id=1&Itemid=2&lang=de

Quote from this site (only in German):

Quote:
Gratis Emulator

Der HP-Emulator ist eine kostenlose Software, die es Ihnen möglich macht, Ihren PC im Unterricht als voll funktionsfähigen Taschenrechner zu nutzen. Zu weiteren Informationen und zum Download geht’s hier.


This text says that the emulator is a free software, so I guess it's no problem to post the direct link here:
http://www.sesco.ch/db/daten/dokumente/hp39gII_emulator.zip

The emulator is dated 10.5.2012 and it seems to be exactly the same version as the currently available 39gII calculators.

I also have a newer version (9.7.2012) which I got from one of the HP developers, but I've promised to not give it away. So for the final version of the emulator on the official HP site you'll have to wait still a few more days/weeks (but it will be freely available as I was told). :-)

Regards,
Franz

                                          
Re: It's not a bug it's a feature
Message #47 Posted by Cristian Arezzini on 15 July 2012, 6:26 a.m.,
in response to message #46 by fhub

Thank you Franz, it works very well even under Linux. Are there major differences with the new one? This one seems pretty good to me!

Cristian

                                                
Re: It's not a bug it's a feature
Message #48 Posted by fhub on 15 July 2012, 7:12 a.m.,
in response to message #47 by Cristian Arezzini

Quote:
Are there major differences with the new one?
No, I've not found any yet, maybe just some internal improvements.
BTW, one very comfortable feature of the emulator is that you can simply enter your expressions with the PC keyboard, almost no need to use the mouse!
The only 2 things I'm missing in the HP-39gII are a CAS and switching between ALG and RPN mode.

Oops, I forgot: it has more (and a bit different) skins, and it includes manuals in many languages.

But as I said: this new (full) version will be available soon (I hope) ... :-)

Edit: In the meantime you can download English manuals from here:
User Guide:
http://www.hpgraphingcalc.org/uploads/9/4/3/8/9438994/hp_39gii_users_guide_english_en_nw249-90001_edition_1.pdf

Quickstart Guide:
http://www.hpgraphingcalc.org/uploads/9/4/3/8/9438994/hp_39gll_quick_start_guide_en_nw249-90201_edition_3.pdf

Franz

Edited: 15 July 2012, 9:02 a.m.

                  
Re: HP 39 GII
Message #49 Posted by Mike Morrow on 13 July 2012, 4:13 p.m.,
in response to message #38 by Charles C(UK)

Some pictures of the internals would be interesting.

                        
Re: HP 39 GII
Message #50 Posted by Charles C(UK) on 14 July 2012, 7:14 a.m.,
in response to message #49 by Mike Morrow

Yeah, that was an omission on my part. I decided to join the forum after I had buttoned the calculator back up. I am not too keen to open it again without it being a necessity. I am sure somebody will do a complete tear down and post pictures somewhere before too long.

I have completed a benchmark of the HP39GII's on-board programming language against Casio Basic running on a 9860G. For each calculator, I plotted out the Mandelbrot set on a 100x60 field of pixels, with a maximum of 20 iterations per tested complex plain location. Elapsed times were as follows:

Casio 9860G 10 min 59 seconds

HP 39GII 46 seconds

The programs were line by line equivalent as far as the languages would allow.

As can be seen, the HP rendered the Mandelbrot set 14.3 times as fast as the Casio.

                              
Re: HP 39 GII
Message #51 Posted by Marcus von Cube, Germany on 14 July 2012, 7:34 a.m.,
in response to message #50 by Charles C(UK)

Can you post the code, please? It might even be worth an article in the articles section of this forum.

                                    
Re: HP 39 GII
Message #52 Posted by Charles C(UK) on 14 July 2012, 10:34 a.m.,
in response to message #51 by Marcus von Cube, Germany

Hmm..., feels like hanging out the dirty washing but here they are. Listings are transcribed via keyboard so there may be typos.

Only straightforward arithmetic is used used (i.e. no built in imaginary number handling or power raising functions, which might negate the comparison).

Marcus tidied up my listings when all my formatting and white space disappeared in the forum editor. See his post below for tidy versions:

Edited: 14 July 2012, 11:10 a.m. after one or more responses were posted

                                          
Re: HP 39 GII
Message #53 Posted by Marcus von Cube, Germany on 14 July 2012, 10:47 a.m.,
in response to message #52 by Charles C(UK)

Thanks! Next time try [pre]...[/pre] around your code:

'*' is substituted for 'x' (times) in the Casio calculator listing.

Casio 9860G Mandelbrot set program --------------------------------------------------------------- Variables X and Y avoided, since the 9860G OS seems to like to keep a hold of them for itself!

ClrGraph For 1->P To 100 #for each screen position on a 100x60 grid For 1->Q To 60 (P-50)/30->A #turn the screen pos. into a complex plane location (P-30)/30->B A->C #buffer the complex number coefficients B->D 0->N # zero the iteration count 1->S # initially, assume the complex number is in the set Do 1+N->N #increment the iteration count A*A-B*B+C->G #compute next real coefficient - hold in G 2*A*B+D->B #compute next imaginary coefficient G->A #update A, ready for next iteration If A*A+B*B > 4 #test to see if we are still in the set Then 0->S #set S to 0 if break-out has occurred IfEnd LpWhile N < 20 And S=1 #repeat until N limit reached or breakout If S=1 Then #if in the set, then turn on current pixel (row, col) PxlOn Q, P IfEnd Next Next

HP39GII Mandelbrot set program -------------------------------------------------------

EXPORT MAND() BEGIN RECT(); #clear screen FOR X FROM 1 TO 100 DO #for each screen position on a 100x60 grid FOR Y FROM 1 TO 60 DO (X-50)/30->A; #turn the screen pos. into a complex plane location (Y-30)/30->B; A->C ; #buffer the complex number coefficients B->D; 0->N ; # zero the iteration count 1->S; # initially, assume the complex number is in the set REPEAT 1+N->N; #increment the iteration count A*A-B*B+C->G; #compute next real coefficient-hold in G 2*A*B+D->B; #compute next imaginary coefficient G->A; #update A, ready for next iteration If A*A+B*B > 4 THEN #test to see if we are still in the set 0->S #set S to 0 if break-out has occurred END; UNTIL (N = 20 OR S=0);#repeat until breakout or N limit reached If S=1 THEN PIXON_P(X,Y) #if number is in the set, then turn on current pixel END; END; END; TEXTOUT_P("DONE",0,80); #all done FREEZE; #hold screen until key pressed END;

                                                
Re: HP 39 GII
Message #54 Posted by Charles C(UK) on 14 July 2012, 10:50 a.m.,
in response to message #53 by Marcus von Cube, Germany

Nice work, thank you.

I originally used 6 as an arbitrary value for the modulus squared when testing to see if a particular Z would iterate itself out of the set. I noticed that most programs use 4. This change slightly shortens the execution times as follows:

Casio 9860G: 10 minutes 43 seconds

HP39GII: 44 seconds

The performance factor in this case is 14.6 in favour of the HP39GII.

Edited: 14 July 2012, 11:19 a.m.

                              
Re: HP 39 GII
Message #55 Posted by Gilles Carpentier on 14 July 2012, 4:18 p.m.,
in response to message #50 by Charles C(UK)

just few others speed tests for the 39GII :

FOR T FROM 1 TO 10000 DO END;

takes about no time... A loop from 1 to 100000 takes ~4 sec

The sum of n first numbers :

EXPORT Test(N)
BEGIN
 R:=0;
 FOR I FROM 1 TO N DO
  R:=R+I;
 END;
 R
END;

Test(10000) gives 50005000 and takes ~1sec (31 with my 50G - with a loop, the 'sum' function use PSI function and is instantaneous)

About graphics :

FOR x FROM 0 TO 255 DO
 FOR y FROM 0 TO 126 DO
   PIXON_P(x,y);
 END;
END;
takes only 3 sec wich means that the calc write 10000 pixels / sec

EXPORT Boite(N)
BEGIN
  FOR I FROM 1 TO N DO
   RECT_P( FLOOR(RANDOM(255));FLOOR(RANDOM(126));
           FLOOR(RANDOM(255));FLOOR(RANDOM(126));
           0;FLOOR(RANDOM(3)));
  END;
  FREEZE;
END

draws boxes on the screen with a black border and random color (grey level) inside.

Boite(100) takes about no time...

Boite(1000) takes less than 2 seconds.

Plot of fonctions is quite instataneous, zoom ...

These are good news... Bad news is that the current ROM version seems to have some bugs with power of complex numbers. I hope this will be corrected soon.

Edited: 14 July 2012, 5:38 p.m.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall