HP 50g?



#13

I am intrigued by what I have read on this forum regarding the HP 50g, but am unsure if it is the right calc for me, so I would like to get benefit of your opinions.

I am a structural engineer, and have been a very satisifed user of the HP 11c and the 32sii. I like the functionality of the 33s in terms of its bigger memory, but the color scheme and chevron layout are problems for me. In my daily work I frequently encounter chain calculations such as summing moments and forces. My primary need is for something that works well as a number cruncher, but that also has programming capability and an equation library. As far as programs go, I typically have programs that calculate the allowable stress for various materials.

My question, is the 50g useful as a number cruncher? Would it be considered overkill? Other posts have given me the impression that the variants of the 49 are difficult to use.


#14

One way to ease into the world of the HP48/49/50 would be to get an HP48g off ebay and try it out for yourself.

Cost? They sometimes go for under $30 rather than $120-150 for a new HP50g.

If you don't like it, you could probably get most of your $$ back by dumping the 48g back on ebay.

#15

The HP50G and the rest of the HP graphics calculators are heavy hitters compared to HP-11C and the HP-32SII. They use RPL as a programming vehicle. Also, built-in are powerful numerical and symbolic math tools that the 11C and 32SII can't touch. The 32SII has SOLVE and INTEGRATE granted, but the HP graphing calculators have much more. For example, the 50G (et al.) can do LU, QR, and SVD decomposition for matrices. Among the non-graphing HP calculators, only the HP15C and the HP41C (with Advantage module) use the LU decomp method in solving systems of linear equations.

#16

If you are comfortable with the programming model of the 32SII, I'd say stick with it. The RPL models are quite a it more complicated to program for someone with a keystroke programming background. Having said that, I actually like User RPL quite a bit. It took a very large investment of my time to get me to where I was comfortable with it. But once I got there, I found the language to be a lot of fun. I'd even say that RPL is "intuitive" with the caveat that you have to beat up your intuition to get there. 8) One other drawback is that coding non-trivial User RPL programs on the calculator itself is difficult. Even with the 49G+ and 50g, where you have a fair amount of screen real estate, the calculator reformats your code to its own idea of what the indentation should be. I find I have to use something like HPUserEdit in order to be productive, which means I need a Windows PC. That's a problem for me since I strongly prefer Linux. But if I do deign to boot Windows, the process of coding with HPUserEdit is quite nice. The code can be tested on a cooperating copy of emu48, and the integration is very, very sweet.

Otherwise, if you find you are beating your head against the limitations of the 32SII or 33S, the only way up in a handheld that doesn't involve TI BASIC is to a 42S or to the RPL machines. The latter are certainly more powerful than the former.

Regards,
Howard


#17

Quote:
One other drawback is that coding non-trivial User RPL
programs on the calculator itself is difficult. Even with the 49G+
and 50g, where you have a fair amount of screen real estate, the
calculator reformats your code to its own idea of what the
indentation should be.

True, the RPL calculators compile the source code to an object,
and then decompile the object for display or editing, thus losing
any user-preferred formatting and comments.

A work-around is to write the source code within a character
string, thus preserving it exactly as written. Then when you want
to compile the source code, use the STR\-> (or OBJ\->) command on
a copy of it.

A problem with using STR\-> is that it may be difficult to
determine just where the problem is when you get an "Invalid
Syntax" error. In this case, edit a copy of the string in the
command line, editing out the " delimiters, and then press ENTER;
this should be more helpful.

Of course, for lengthy programs, the larger screen and QWERTY
keyboard of a PC is a big advantage. Transferring a program to the
calculator is reasonably fast, even with the 48 series. If you get
an "Invalid Syntax" error, insert

C$ $
on its own line after the header to make the rest of the file a
string, and proceed as above.
Quote:
I find I have to use something like HPUserEdit in order to be
productive, which means I need a Windows PC. That's a problem for
me since I strongly prefer Linux. But if I do deign to boot
Windows, the process of coding with HPUserEdit is quite nice. The
code can be tested on a cooperating copy of emu48, and the
integration is very, very sweet.

Well, suit yourself, but I find it much easier to just use a text
editor, using translation mode 3 for the transfers. I happen to
prefer TSE, but any text editor, even MS Notepad, suffices. Surely
any Linux user would be familiar with some text editor? For that
matter, any "word processor" should work too, as long as the
source file is saved as "plain text". If you do this, then you'll
soon learn the translation sequences for non-ASCII characters that
you use frequently.

If you need a reminder of the translation sequences, the following
User-RPL program for the 49 series builds a handy string with the
decimal value, "binary" value, the character, and the translation
sequence for characters 128-255. Note that the "binary" value is
mode (BIN, OCT, DEC, or HEX) dependent, and whether a character or
its translation sequence appears in the last column depends on the
translation mode stored as the last element of IOPAR (I recommend
translation mode 3), when the program is run. How any character
appears depends on the current font when the string is viewed. To
view the string, press TOOL and then VIEW, or put it into the
command line editor with CursorDown or LeftShift CursorDown. Be
patient; this takes about 16.5 seconds to run on a 49G, or 6.2
seconds on a 49g+, but once you've run it, you can simply store
the string for later use. A SysRPL version of this is available in
my "ASCII on SD" package.

%%HP: T(3)A(D)F(.);
@ For 49G and 49g+ (and, I guess, 48gII and 50g) only.
@ Checksum: # A162h
@ Size: 116.5
@ Download in exact mode.
\<< @ Begin program.
"" @ Start with empty string.
128 255 @ Relevant character values.
FOR n @ Start loop.
"\010" @ LineFeed string.
n @ Loop index value.
" " @ Space string.
OVER @ Copy of loop index value.
R\->B @ Convert to "binary" integer.
OVER @ Copy of space string.
+ @ Append space to binary string.
PICK3 @ Copy of index value.
CHR @ Convert to character string.
PICK3 @ Copy of space string.
OVER @ Copy of character string.
# 2F34Eh SYSEVAL @ KVIS for 49G and 49g+ (converts
@ character to translation sequence).
+ + + + + + + @ Concatenate strings.
NEXT @ Loop end.
"\010" + @ Append LineFeed.
\>> @ End program.
Here's a version for the 48 series. Note that the entry point for
KVIS is different, and it uses 3 PICK instead of PICK3. Use
CursorDown to view the string. It takes about 23.5 seconds on a
48SX, or 14.8 seconds on a 48GX.
%%HP: T(3)A(D)F(.);
@ For 48SX/S/GX/G/G+ only.
@ The usual dire warnings to be careful with SYSEVAL apply.
@ Checksum: # 58A5h
@ Size: 128.5
\<< @ Begin program.
"" @ Start with empty string.
128 255 @ Relevant character values.
FOR n @ Start loop.
"\010" @ LineFeed string.
n @ Loop index value.
" " @ Space string.
OVER @ Copy of loop index value.
R\->B @ Convert to "binary" integer.
OVER @ Copy of space string.
+ @ Append space to binary string.
3 PICK @ Copy of index value.
CHR @ Convert to character string.
3 PICK @ Copy of space string.
OVER @ Copy of character string.
# 2FEDDh SYSEVAL @ KVIS for 49G and 49g+ (converts
@ character to translation sequence).
+ + + + + + + @ Concatenate strings.
NEXT @ Loop end.
"\010" + @ Append LineFeed.
\>> @ End program.
Of course, in modes 1-3, a LineFeed not immediately preceded by a
CarriageReturn is translated to a CarriageReturn LineFeed pair on
transfers from the calculator, and a CarriageReturn LineFeed pair
is translated to a LineFeed on transfers to the calculator. In
modes 2 and 3, the translation sequence \010 can be used for
LineFeed, and \013 for CarriageReturn. Also, in modes 2 and 3, the
translation sequence for \ itself is \\ (or \092). In mode 2, you
can also use the translation sequence \nnn for characters 0-159,
and in mode 3, you can use \nnn for characters 0-255, where nnn
represents the 3-digit decimal value of the character.

Regards,
James


#18

I wrote:

Quote:
To view the string, press TOOL and then VIEW, or put it into the command line editor with CursorDown or LeftShift CursorDown.

But LeftShift CursorDown (EDIT) decompiles each \ to \\. Better to use just CursorDown (EDITB).

Regards,
James

#19

Actually, I find the RPL models very easy and intuitive to use, but then too, my experience with the HP calculators started with the 28S (an RPL model), and I have little experience with "Classic RPN" models.

The RPL models may well be "overkill", but you really don't need to use all of their capabilities. They have features that I'll never use, because I don't have the mathematical knowledge to understand what they're supposed to do. The bigger problem may well be that you'd have to change some of the ways that you've gotten used to doing things on the 11C and 32sII.

Perhaps a very good introduction to RPL models for Classic RPN users would be Bill Wickes's HP 41/HP 48 Transitions, and for more in-depth looks at RPL, see his Insights books, all available on the current Museum CD-ROM set / DVD-ROM. See:http://www.hpmuseum.org/software/swcd.htm.

Regards,
James

Edited: 10 Aug 2006, 2:08 p.m.


#20

thanks all for your replies.

I doesn't seem that spending the $ on the 50g would make sense for me. However, I am jealous that "high-end" community gets a new calc with something approaching the traditional HP color scheme, but us at the "lower end" are stuck with the 33s in its current form :)

I am very familiar and comfortable with RPN programming ala the 32sii, but the small memory is a huge problem for me. As has been discussed at great length, the 33s does have the bigger memory, but the design of this machine is flawed in my opinion. I find myself using my 32sii for plain number crunching, but when access to programming is helpful I use my 33s. Maybe in the future I will pick up one of the RPL machines from ebay and give it a try.


#21

As discussed at length in other recent threads, there are some projects to manufacture a new RPNNN calc of the kind you (and me) know for long. Eventually it may be seen as an HP42SX, HP15CX, HP32SL or whatever you like. Things take their time, but they are moving, and even in the right direction so far IMHO. So my recommendation is: watch it and deliver your input - that's the best way to make sure you'll (one day) get what you are looking for.


#22

Quote:
As discussed at length in other recent threads, there are some projects to manufacture a new RPNNN calc of the kind you (and me) know for long.

I'm a newcomer, so I don't know where these are, or what they are. Can you tell me where to find them, or where, approximately, to look? Thanks.


#23

Hi Larry,

you will find such activities if you scan the forum for keywords like "OpenRPN" or "layout". Or you look for posts of particular authors like Eric Smith, Richard Ottosen or Hugh Evans.

Caveat: Mathematically speaking, said conditions are neither necessary nor sufficient. I.e. there is more, of course, but this will get you started.

Happy surfing!

Edited: 19 Aug 2006, 3:14 p.m.

#24

I have also an HP 33S that was intended to be used as a number cruncher, but I must admit that the 4 item deep stack as too strong a limitation for that.

Ok, I previously used an HP28S for this task, but I cannot get used to constantly monitor the stack depth and make continuous used of stored variables.

With a 28/48/50 you will be able to do your calculations by entering formulas in a single shot. That alone is worth the upgrade in my opinion.


#25

For me, the depth of the stack on the 32sii or 33s has never been a problem. I can do what I consider complex equations with no problem.

#26

I've only run into the 4 stack issue a few times, and generally it was when I was trying to break it by doing extra long problems. Of course, when I do everyday math (on an engineering project, or a problem set), I tend to use the STOre and ReCaLl very heavily so I can fix it if I make a mistake.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP 50g trilogy. The new HP 50g Blue (and II) Pablo P (Spain) 18 1,436 09-19-2011, 03:08 AM
Last Post: BruceH

Forum Jump: