50G ideas

[BD]

Recently found this forum, and I haven't paid attention to the HP calc culture for a long time. Amazing what has happened since the 15C which I used for engineering school, which since then has mostly been riding around in the truck to compute fuel efficiency ( now replaced by a $6 Casio, keeping the 15C in the home! ).

Progressive improvement ideas for the 50G and / or its replacement:

- Fix outstanding bugs.

- I thought I read a reference somewhere that the periodic table and / or some physical constants are out of date, and these should be updated.

- Possible additional optimizations to speed the emulation more.

- Considering all the memory which is available, add inline comments and also per-routine or per-object comments, where we can place stack diagrams and functional descriptions. Probably won't be backwards compatible with older ROMs, though.

- Add break and continue commands. Likewise, will require anyone using these to update their ROMs.

- A classic RPN mode would be interesting to add at little expense.

For a new machine:

- Keep user RPL compatibility with any new machine. To the extent that anyone is still programming these machines any more, this is what they use and they probably would want the source to work on a new machine. RPL is plenty powerful for what a calculator usually needs to do, and there is such a massive collection of functionality already built in.

- USB On-The-Go. This could allow the connection of many kinds of off the shelf sensors, controls, storage, and interfaces. The new calculator could become a mobile data collection device or control with built in physical key pad and reasonable display and battery life, plus program-ability.

- Speed could be nice, but I'd release a slower version of the above earlier if necessary. A 50G with the same emulation but updated ROMs and USB On-The-Go could be a nice machine.

One area where a physical calculator beats a phone or tablet is practical usage on a small desktop space, such as those tiny 3/4 desks which they had in the college lecture halls. Small format, physical keys, no-slip foot pads, endless battery life, and much cheaper than any phone or tablet. Just what you need in college and maybe in the field.

[Mark Hardman]

********************************************

**  This post reserved for Software49G    **

**  "beating a dead horse" and marketing  **

**  the O.S. Extension Pack.              **

********************************************

[Damir]

ROTFL!

[Raymond Del Tondo]

If I were a 50g user, I would be glad if at least one person still developed professional software for that platform;-)

Ray

[Reth]

IMHO the best for the HP50 is to be discontinued.

[Eric Smith]

And how would that benefit anyone?

[Reth]

This may open the door for something useful instead.

[Eric Smith]

I don't see how. Assuming you're talking about a new high-end RPL calculator or the like, there are two problems:

1) There doesn't appear to be any significant market for one.

2) It would take a lot of resources to develop a new one.

Neither of those problems is solved by discontinuing the 50g.

[Reth]

Quote:

---

I don't see how. Assuming you're talking about a new high-end RPL calculator or the like, there are two problems:

1) There doesn't appear to be any significant market for one.

2) It would take a lot of resources to develop a new one.

Neither of those problems is solved by discontinuing the 50g.

---

1) And there is significant market for 50g? I don't think so, hence it should be abandoned.

2) Apparently not. See ongoing projects like WP34 and others - done in spare time.

50g is a pathetic successor of the great HP48 and should be put to rest in peace.

[Mike Morrow]

Quote:

---

50g is a pathetic successor of the great HP48 and should be put to rest in peace.

---

Total hyperbolic nonsense!

Having purchased and used the HP 48SX in 1991, followed by the HP 48GX in 1996, I almost gave up on HP calculators after using these slow high-priced RPL-clunkers. These were terrible machines except for keyboard, with very expensive accessories of very modest capability. LCD quality was abysmal until the last few months of GX production! Firmware could never be upgraded, even though many important revisions were required before rev. R for the 48GX ended any further 48 development.

I finally purchased an HP 50G in 2007 after playing with a 49G+ I bought for $20 at a flea market. It surprised me that HP did not try to come up with some sort of proprietary memory card, as did the 48-series, using instead the common SD card. The 50G supports long calculations when powered through the USB connector. It comes standard with a large array of tools in the development library that could only be dreamed of in HP 48 world. It is not perfect, but it is easily all things considered the best handheld calculator ever sold by HP, or by anyone else for that matter. I still dislike RPL, having been a user of RPN since 1976, but the 50G is worth the trouble.

[Reth]

Well that's your story, mine is different. I bought all of them when they came out. I still use occasionally the 48gx, 49g+ gathers dust somewhere, 50 got sold because I find it useless. I don't care too much about computing power but the built, the fill, the keyboard even the screen - latest b/w ones are OK, bigger system font. As I said before, 50 would be acceptable to me if it had the size of the hp42.
BTW the only downside of hp48 I see in sharing cursor keys with alpha chars.

[Eddie W. Shore]

Quote:

---

Total hyperbolic nonsense!

Having purchased and used the HP 48SX in 1991, followed by the HP 48GX in 1996, I almost gave up on HP calculators after using these slow high-priced RPL-clunkers. These were terrible machines except for keyboard, with very expensive accessories of very modest capability. LCD quality was abysmal until the last few months of GX production! Firmware could never be upgraded, even though many important revisions were required before rev. R for the 48GX ended any further 48 development.

I finally purchased an HP 50G in 2007 after playing with a 49G+ I bought for $20 at a flea market. It surprised me that HP did not try to come up with some sort of proprietary memory card, as did the 48-series, using instead the common SD card. The 50G supports long calculations when powered through the USB connector. It comes standard with a large array of tools in the development library that could only be dreamed of in HP 48 world. It is not perfect, but it is easily all things considered the best handheld calculator ever sold by HP, or by anyone else for that matter. I still dislike RPL, having been a user of RPN since 1976, but the 50G is worth the trouble.

---

Could have not said it any better.

[Gilles Carpentier]

"50g is a pathetic successor of the great HP48 and should be put to rest in peace. "

Hummm.. I don't know who is pathetic here ....

[Reth]

Do you want me to give you a hand? :-)

[Eric Smith]

Quote:

---

And there is significant market for 50g? I don't think so, hence it should be abandoned.

---

No, doesn't make sense. It doesn't require nearly as large a market to justify continuing making a product which has already been developed (sunk costs), as to justify making a new product (huge R&D costs).

Quote:

---

Quote:

---

It would take a lot of resources to develop a new one.

---

Apparently not. See ongoing projects like WP34 and others - done in spare time.

---

As awesome as WP34 is, it's at least an order of magnitude less work than developing firmware for a 48/49/50 class product. And that's ONLY for firmware development; you still need to develop the hardware also, and that is a major investment also.

[Paul Dale]

Quote:

---

...it's at least an order of magnitude less work than developing firmware for a 48/49/50 class product.

---

I can only agree here.

- Pauli

[Reth]

Again management/business related views from an engineer

[Walter B]

Hmmmh, so what's what you want, what you really really want? Discontinuing the HP 50g would leave this segment empty, ready to be completely taken over by TI, Casio, Sharp, and whoever else thinks he can cover that. HP 39GII is for pupils where TI rules. A serious nongraphic scientific is not made by HP anymore. Shall HP discontinue supplying engineer's tools at all? Hail to the Wall Street?

[Reth]

what I really really want is peace and love worldwide

[Walter B]

Hmmmh, but that's not the reason why you vote for discontinuing the HP 50G, isn't it? AFAIK it's not used as an artillery computer yet like the HP 41C [|-/

Edited: 16 Aug 2012, 5:08 p.m.

[Reth]

Quote:

---

Hmmmh, but that's not the reason why you vote for discontinuing the HP 50G, isn't it? AFAIK it's not used as an artillery computer yet like the HP 41C [|-/

---

boolean operations in the first sentence don't work ;-)

I personally used 15cm "Aristo Studio" slide rule for that purpose when I was in the army circa 1976, quite successfully.

[Walter B]

Quote:

---

boolean operations in the first sentence don't work ;-)

---

Point taken :-) BTW, how many foreign languages do you write?

Anyway, IMHO you are continuously refusing to respond to the questions asked in post #18. Given your brains, you must have recognized what was asked. Still waiting for a serious answer :-/

Edited: 17 Aug 2012, 2:26 p.m.

[Eric Smith]

Yes, I'm an engineer, and yes, a few things I've described are business matters. However, they aren't complicated business matters that require an MBA to understand. They're really quite simple and straightforward things that are covered in engineering economics classes and texts.

[Reth]

Quote:

---

... They're really quite simple and straightforward things ...

---

It's a fine line that separates what's simple and what's not quite so. The older one gets the better judgement they possess.

[Bart (UK)]

Quote:

---

Again management/business related views from an engineer

---

Engineers make better management/business related decisions than managers/businessmen.

[Ethan Conner]

Amen

[Pal G.]

Should HP only continue to MAKE the product, or should HP also continue to SUPPORT the product. I believe the lack of support or updates is what drives many mad.

Oh, the joy when some iPhone or Android developer updates one of my stale apps, even if only to kill a few, minor bugs.

[Thomas Radtke]

There are indications RPL is given up after the 50G. I doubt you will see any further updates to it. Same with RPN models. The last new RPN scientific calculator was the 35s, which hasn't seen any updates since 2007. A recent remake of the 15C suffered from serious bugs and is discontinued by now, also no updates.

The focus is clearly on financial and educational calculators.

Edit: Slide rules are great to calculate fuel consumption. I always have a 0.15m SR in my car. No worry about batteries :-).

Edited: 12 Aug 2012, 3:22 a.m.

[Eric Smith]

Quote:

---

The last new RPN scientific calculator was the 35s, which hasn't seen any updates since 2007. A recent remake of the 15C suffered from serious bugs and is discontinued by now, also no updates.

---

I wouldn't write off RPN scientific calculators just yet. :-)

[Reth]

I would, unless they come up with something like free42 in the skin of the HP42S but chances are slim. WP34S with fixed SLV and better screen would do the trick.

[Walter B]

Quote:

---

WP34S with fixed SLV and better screen would do the trick.

---

I probably missed something: What's wrong with SLV?? TIA for enlightenment.

And yes, that terrific display :-/ It's beyond our power, however :-(

[Reth]

It was discussed here some time ago. SLV doesn't match results of other solvers in all circumstances. Apparently the result depends also on the current FIX setting. Identical programs run on HP42, HP48 and HP15c in certain cases give close answers while WP34 fails. The thread mentioned strange SLV behaviour.

[Paul Dale]

So. different == broken now?

- Pauli

[Reth]

Sadly - yes, as far as I am concerned. Different == wrong ;)

[Paul Dale]

Feel free to submit the source code for a completely HP compatible solver. It is only keystroke programming after all. How hard can it be????

- Pauli

[Reth]

Too hard for me, I'm not that smart, but you can do it!
I'll be waiting for it anyway.

BTW I was wondering if Thomas Okken's free42 could be used as example?

Edited: 15 Aug 2012, 2:49 a.m.

[Walter B]

Quote:

---

Different == wrong ;)

---

AFAIK the solver "bug" is the
one where the solver finds a discontinuity/pole that crosses zero in
some cases. e.g. it can locate pi/2 when solving tan(x). The
complaint being that it doesn't avoid such conditions as well as HP's
solver or at least in some specific cases it doesn't. Is this true? Just to make sure we got your problem correctly. Else please provide examples of what you consider buggy.

[Reth]

I will, Walter, just not right now. The previous thread should show the basics though.

Don't get me wrong guis, I *love* the wp34 paradigm and this (little omission) is just driving me mad ;)

[fhub]

Quote:

---

... and this (little omission) is just driving me mad ;)

---

Well, maybe you should see it positive: the WP34s SLV is an 'improved/extended' solver - it not only solves for roots but also for poles! :-)

So you just get both interesting values for a function, depending on your entered initial guesses (starting interval).

Franz

[Reth]

:-) that seems to be the case. So I need to know the exact answer in order to use SLV properly. ;)

[fhub]

Quote:

---

So I need to know the exact answer in order to use SLV properly. ;)

---

Exact? Of course not! But it would indeed be good to have at least an idea where the root might be, or which root (of multiple solutions) may be of interest for you, so you can chose an appropriate starting interval. And I guess that's not different for most other root solvers in calculators (except those with a built-in CAS).

Franz

[Reth]

that was a joke, Franz

the same initial guesses/intervals lead to different solutions on different platforms.

[Reth]

Quote:

---

it would indeed be good to have at least an idea where the root might be, or which root (of multiple solutions) may be of interest for you, so you can chose an appropriate starting interval.

---

what about initial guesses of 0 and 1 and getting negative infinity as an answer?

[Walter B]

Quote:

---

what about initial guesses of 0 and 1 and getting negative infinity as an answer?

---

IMHO there's a major piece of information missing. Guess what!

[Eric Smith]

I'm not sure which "they" you're referring to, but there may be more than one "they" that could come up with new calculators.

[Reth]

HP, but others are welcome too

[Gilles Carpentier]

Hi

Quote:

---

- Considering all the memory which is available, add inline comments and also per-routine or per-object comments, where we can place stack diagrams and functional descriptions. Probably won't be backwards compatible with older ROMs, though.

---

I'm not sure to understand well but:

- If you wrote your program on a PC, the @ does that

@ My comments

@ Stack diagram

@   ...

- On the calc, it's an easy way in fact. you can just create 2 news words. For example c\ and \c and do:

c\ " here are my comments...  datas stack"  \c

carriage returns are allowed in comments with shift .

'c\' does nothing (just to improve readibility) and begin comment bloc

'\c' is just DROP

You can also just do something like this

"// my comment. // is here just to show that this text is a comment and a drop will follow. carriage return allowed ...//" DROP

For interactive use, I think it would be interesting to work like the IBM AS400 (eSerie) does. If you don't know the parameters for a function, just do :

MyFunction _F4_

and then you get an input form with on line help (help for the function, and help for each argument (an argument may be another function and another _F4_ is possible 'en cascade' . You can do this for your own commands.

For on-line help, you have :

http://www.software49g.gmxhome.de/

Edited: 12 Aug 2012, 5:24 a.m.

[George Litauszky]

And an other idea: See this post.

[Gilles Carpentier]

Hi George,

you wrote

Quote:

---

(...)
- Separate zeros to the left side. (SORT)
- Search the first nonzero element., (1 POS) and drop zeros from the list. (SUB)

---

Why not

1. << DUP NOT { DROP } IFT >> DOSUBS

or with the excellent Gofer list library

<< >> Filter

Here another idea, not very fast (58s) but much small :

«

  1. 0. -> n m

  «

   1. 999. 2. Seq

   WHILE  DUP 'n' INCR GET DUP 'm' STO OVER SIZE < REPEAT

    1. « NSUB m MOD NOT { DROP } IFT » 

    DOSUBS

   END

  »

»

But I think your remark is more about the speed of SORT to be improve ;D
I agree and in general, speed of list manipulation

PS : Here a full stack program (4.5 sec for 'lucky numbers' < 1000 it's 12 times faster that the list manipulation with same algorithm)

« 1. 0. -> n m

  «

   CLEAR  999. 1. FOR n n  -2. STEP   

   WHILE 'n' INCR PICK DUP 'm' STO DEPTH < REPEAT 

    DEPTH DUP m IREMAINDER - m FOR k

      k ROLL DROP

    m NEG STEP

   END

  »

»

85 sec. for 'lucky numbers' < 10.000

Edited: 13 Aug 2012, 3:11 a.m.

[Gilles Carpentier]

Have a look at http://www.hpcalc.org/details.php?id=2828

Sort a list of 500 numbers takes only 0.28 sec (vs 10.9 sec)
A 1000 elments list sort 0.58 sec !

LSORT is to use in the same way as SORT with little limitations

[Ethan Conner]

Look Here

[George Litauszky]

Hi Gilles,

Thanks for the help. Your full stack program is admirable! I'm beginning to believe: The legend of the stack sytem calculators is really true. This speed in User RPL is incredible.
I wrote a small completion to the front it to read the initial parameter from the stack to variable 'IN':


<< IN DUP MOD IF NOT THEN 'IN' DECR CLEAR ... IN 1 FOR N ... -2 STEP ..


And to the end: DEPTH ->LIST REVLIST.

These small modifications increase the run speed with 1 sec.

Thanks for the links too, I will testing these utilities.


George

Edited: 13 Aug 2012, 12:55 p.m.

[BD]

Quote:

---

- USB On-The-Go. This could allow the connection of many kinds of off the shelf sensors, controls, storage, and interfaces. The new calculator could become a mobile data collection device or control with built in physical key pad and reasonable display and battery life, plus program-ability.

---

Any thoughts about the usefulness of USB On-The-Go?

[Tim Wessman]

Was going to respond but ended up not for some reason.

The thing about USB-OTG that most people don't realize is that you STILL have to have drivers in the OS. You can't just plug in any old USB and have it up and running. To connect a printer, you have to have a driver that supports that printer. For a usb-serial converter, you have to have a driver.

Now you can definitely support a few generic classes such as HID, and maybe mass storage, but it is still going to be very very difficult to support everything anyone wants to do. Most of those "off the shelf" things are going to require drivers.

In short, you are left to the whims of the development team who are at the whims of those higher up the chain. :-)

TW

Edited: 14 Aug 2012, 6:58 p.m.

[Cristian Arezzini]

Quote:

---

The thing about USB-OTG that most people don't realize is that you STILL have to have drivers in the OS.

---

Do the drivers for "non-standard" peripherals have to be hard-coded in the OS? Couldn't they be left to third parties to do? (Meaning enthusiasts, as I don't suppose any hardware vendor would develop drivers for a calculator.)

[Tim Wessman]

I am not aware of any embbed systems that allow the user to load a driver. I am excluding of couse those that you have access to the complete source and just looking for a mechanism designed to allow loding by the end user. I honestly don't see how it could be possible. Granted, I am no USB expert.

TW

[Guy Dufour]

This site provides a quick and easy introduction to USB :

http://www.beyondlogic.org/usbnutshell/usb1.shtml

The operating system doesn't have to load drivers to enable applications access USB devices, it would be possible to design the OS so that it provides some functions to access the devices directly through USB endpoints.

I have programmed a few applications on Windows and OS X for devices that do not hae a driver and both those OS provide some functions to access USB devices directly.

This approach is good enough for low speed/low volume applications. For high speeds, code that runs at the driver level and that can access DMAs and Interrupts is required to keep up, and usually, applications are too low priority for such uses.

Recently I had to program an application for an Android Tablet that had read data from a USB data colection device used in hospitals to collect vital signs from various monitors. There were no Android drivers but Android 4.0 offers functions to access the USB bus so that app was made to work :)