Has the HP-49G been discontinued?



#12

I looked at the HP website after reading the post below. And I couldn't find the 49G and some older buissines calculators that were still listed a few weeks ago.


Harry...still waiting for help with that HP-21...


#13

The news doesn't look good; check the official HP online catalogue;

http://www.shopping.hp.com/cgi-bin/hpdirect/shopping/scripts/generic_store/generic_subcategory_view.jsp?BV_SessionID=@@@@1937090404.1040879794@@@@&BV_EngineID=ccdcadchdldjgfkcfngcfkmdfondfgf.0&category=calculators&subcat1=graphing&cat_level=1

A few weeks ago the 48G+ and 49G were available on this site. The GX is probably being retained for the time being, because of the large demand for HP48 RAM card software in the states. The news for RPN looks grim !


#14

I'm not so sure, that the news for RPN looks grim. Remember that thread of a couple weeks ago, where Dave Hicks mentioned that HP had urgently requested he send RPN manuals to somewhere in the Far East (Taiwan?)?

It's not conceivable that contemporary engineering would be needing manuals in order to reverse-engineer RPN. There are still too many "examples" already extant (although I've always wondered if HP used Chebyshev polynomials to calculate transendental functions, some references to internal specs, *not* in manuals, but HP probably has the originals, might clarify exactly the methods used).

But needing examples of manuals in order to write new manuals, that makes a lot of sense. There should be about as many (RPN) manuals as calculators, but hey, if you lose one of the two, which do you need the most, the calculator or the manual :)? So I read this request from HP to Dave as strong evidence that 2003 will bring us some new _RPN_ calculators.

And considering how easy it would be to implement, it seems likely that they'll be software-switchable, RPN & Algebraic (_aka_ the 49G), if only because that expands the market.

OK, I can already hear the objection, the 49G runs RPL (my favorite) rather than RPN. But think of such as the 38G and the 27S. They have "history stacks" that look a lot like RPL and RPN, respectively. So in this case, the difference is minimal, maybe these will even have three-way switches: DEG, RAD, or GRAD; xyz, xR{theta}, or x{theta}{phi}; .AND. ALG, RPN, or RPL.

Now whether you call this a Reverse Polish calculator that does Algebraic, or an Algebraic that also does Reverse Polish, is of no consequence. But based upon recent trends, I'll bet any "combos" are marketed as the latter.


#15

Hi..

>[Glen Kilpatrick wrote:]
>It's not conceivable that contemporary engineering
>would be needing manuals in order to reverse-engineer
>RPN. There are still too many "examples" already extant
>(although I've always wondered if HP used Chebyshev
>polynomials to calculate transendental functions, some >references to internal specs, *not* in manuals, but HP
>probably has the originals, might clarify exactly the
>methods used*

Yes, whether the calc is RPN or Algebraic is independent of the algorithms used for log/trig functions. And any mildly competent programmer can create an RPN-like shell, etc in the C language. The orig challenge in doing the orig HP or even TI calcs was to do a whole calc - including log/trig funcs - in about 1-2 Kwords of ROM. (As I recall, roughly equivalent functionality TI calcs took more ROM space than
similar HPs becuase TI used a kludgy 4-bit microcontroller, while HP's instruction set was designed from the outset to save code space for calc applications.)

Even today, I'd say that a lot of Asian calc mfgrs don't necessarily know a whole lot about their algorithms.

HP, at least thru the 41 series, seems to use CORDIC shift/add algorithms for higher-order functions (not square root - that is done via an algorithm that roughly looks like division). Between some pre- and postprocessing steps the CORDIC algorithm delivers one digit of the result (within the internal processing domain) per iteration. There may be range reduction/scaling issues ("unwinding the circle" for trig functions for example), and some postprocessing (say, deriving one trig function from another or change of bases of logs) before the *actual* result is returned. When later calcs (42,32,48, etc) came out that supported a higher dynamic range (+/-9.9E+/-499 instead of +/-9.9E+/-99) there could've been some algorithmic changes. But I don't think so - I think fundamental algorithms have had enough time spent on them, modelling them, testing, etc that a co like HP would be loath to change them. CORDIC was suitable for log/trig functions on older/slow calcs because it wasn't that much more complex than division.

Other methods do exist: rational function approximation and Chebyshev (and other) polynomials. Some of these require use of division. And contrary to what you learned in calculus class, Taylor's/McLaurin's series aren't that useful for accurate & efficient function approximations.
These involve approximating the function under question over a VERY LIMITED RANGE and pre/postprocessing results.

X86 and other CPUs with floating-point engines have changed design over time. The 80x87 NPU chip, and its on-board derivatives up thru the 486, used CORDIC methods for log/trig functions: they were controllable algorithms with predictable error behavior and didn't take much microcode space on these NPUs.

However CORDIC is essentially serial in nature: you're delivering one bit, hex or BCD digit per iteration. [I believe, IIRC, if you try to speed things up taking bigger "chunks" (say, 4 digits at a time) there is no gain in internal behavior becuase, well, "if you bite off too much" on one iteration, you may often "have to spit some back".] And then internal tables of shifted input values that drive CORDIC would have to be large too.

To have faster results - when fast hardware multiply and divide are available, then nonCORDIC methods may be superior (in terms of speed; error behavior may need some real modelling and analysis). Also some processing steps of these nonCORDIC methods could be parallelized (with additional hardware) if desired. The real art of these designs is to take a system that has an N-bit register set and deliver N bits of result - instead of, say, N-2 result bits with the last 2 bits being "slop". AMD, Intel and Cyrix all have differing methods of doing their transcendentals. There are some papers out there about how Cyrix did theirs, as I recall.

Bill Wiese
San Jose, CA

#16

RPN, RPL -- whatever. I just hope they include the 9G's latest innovation: "4 basic operations (+, -, *, /) to solve wide range of problems ... " (From HP's 9G web page.)

Indeed, I will go so far as to predict that, with the development of the 9G, those features will become de rigueur for makers and users of calculators of all types.

(I couldn't resist . . . )


#17

HI;

Paul, you got it! That's why they need the old manuals so badly...

(Could not resist, too...)

#18

According to "Scientific Analysis on the Pocket Calculator", by Jon M. Smith (Wiley, 1975), p. 39:

"An interesting aside is that the logarithmic, exponential and transcendental functions and their inverses and hyperbolic counterparts are typically generated in pocket calculators with read-only memories (ROMs). These memories generate the numerical values of these functions using Comer functions. Comer functions do not implement series expansions approximating polynomials. They are hardware functions that generate the numerical values of the mathematical functions in which we are interested. In a word, function evaluation on the pocket calculator is done to high precision using read-only memories and hardware implementations of the mathematical functions".

So: Comer functions.

The same book spends quite some time on Chebyshev polynomials as a way of getting a quickly-converging polynomial equivalent to other power series expansions.

Best,

--- Les


#19

Umm,

Maybe SOME early nonHP/TI sci calcs used these functions. (Some early pocket sci calcs had only 5+ digit accuracy on log/trig functions, perhaps these were the ones. I recall National Semi and early early Casios and Sharps as being a bit doubtful. Even an APF Mark 50 (??) that I had in mid 70s I realized had some compromises in log/trig functions.) And I think some of the folks writing these early calculator 'how-to' books may not really have understood 'under the hood' issues of tolerable speed vs. power consumption vs. chip area (price) vs. accuracy - some books still made noises about Taylor series!

I cannot readily find any reference to 'Comer functions'; perhaps they are referring some kinda multi-ROM table with some feedback.

But I'm sure that ROM tables - even with a bit of structural compression and some numeric processing tricks -
would be unsuitable for more than mediocre accuracy. Chip area was just TOO precious, so some sort of stored-program microcode method with only limited ROM-table driven concepts, would be used.

[CORDIC methods typ. require an N-value table for N digits of precision. That is, for 8 digit accuracy, a table of precalculated known values of func(1), func(.1), func(.01), func(.001),...., func(.00000001) is required.]

If CORDIC shift/add methods did not exist, the whole history of the personal pocket scientific calculator, time of introdcution, time of mass marketing, the pricing curves, etc would be vastly different - meaning delayed several years. I suspect something like introduction of first basic pocket scientific (say, at the HP35 or TI SR50 level) would've been delayed to about 1976 years to get it to appropriate price point because just too much ROM (chip area = $$) would be required. Or compromises would be made: only sin() and atn() would be provided and the user would have to derive others from trig identities.

Chebyshev, other polynomial methods or rational function methods would NOT have been used on mid-70s lower cost calcs due to speed and memory limitations. Some of these methods require divisions. (Though I believe some early-70s nonconsumer desktops - Monroe? - may have used Chebyshev or polynomial approximations for their transcendentals.)

Bill Wiese
San Jose, CA


#20

The reference to "Comer functions" has also stumped me, as I've seen no other reference to it. However, I suspect that the author had HP/TI calculators *specifically* in mind in writing that, as the book specifically discusses the HP-35, 45 and 65 (as well as the SR-50). In fact, the Preface states,

"My thanks to the people at Hewlett-Packard who reviewed and critiqued the manuscript, and in particular to the HP-65 chief engineer, Mr. Chung Tong".

Interesting that the reference to Comer functions slipped past the reviewers at HP, as well as Dr. Richard Hamming, at Bell Labs. . .

Sorry if I implied that Chebyshev polynomials might be used in a calculator. Chapter 8 of the book of course discusses the *use* of Chebyshev and rational polynomial approximations by user *equipped with* a calculator, and using economization.

The paragraph I quoted is the only reference in the book to the implementation of transcendental functions in scientific pocket calculators.

Best,

--- Les


#21

Three relatively recent (80s) TI machines used polynomials (exact kind unknown) : the CC40, then the later TI95 and TI74 - for no known reason. As the CC40 was obviously derived from the TI99/4A home computer (but with very different processors and architecture), this may be related to a more desktop philosophy.

On ROM tables, there are machines which calculate the factorial at far too suspicious speeds, and now that ROM is cheap it is possible that the 70 possible results (for a 20-decade calculator) may be pre-calculated. It's the only function I think which can be a candidate for such an optimization.

A problem with CORDIC is that the *maximum* precision is hard-coded (you can calculate at a lower precision using the same tables - see Sharp's switchable 10 or 20-digit precision Basic machines).

Extending the range of representable numbers seems like a silly idea. Who needs numbers larger than 10^100 ? This is pure marketing. Note that no transcendent functions have meaning on this extended range : sin can't be computed, atan takes numbers between -1 and 1, exp overflows, and log can be calculated easily with some scaling. It is probably featuritis like hyperbolic functions.
Also, who cares about 24-digit precision (like the 30S) ?


#22

Not to quibble, but my HP-32S calculates (for example) the result of 5.2! as 169.4061 (to the four decimal places I've currently specified for display).

Try entering a non-integer and seeing how fast it calculates. If it works and it's still fast, there's got to be another explanation . . .

By the way, if the factorial has been generalized to (positive and negaitve!) reals below some practical limit(s) of absolute value(s), is there an inverse of the factorial function? Seems like there ought to be, but for what it might be used is beyond me. Comments?


#23

Well, surprise, surprise! The ol' memory is slow, but not completely gone. In the Forum's most recent archive, there's a whole thread on this factorial/gamma function topic -- I even participated.

(I wonder what other gems of knowledge lie archived in those files . . . )

#24

You're 100% right, but most calculators only calculate the factorial, which is defined for non-negative integers only.

There's no such thing as an inverse for the gamma function, as some values (here ALL !) can be reached from different inputs (here an infinite number !) *unless* you put a condition on the input.

I have an old family recipe to calculate the inverse of gamma for values greater than 2, like this :
1. Input X
2. Solve 'Y.log(Y)=X' for Y
3. Calculate Z=Y.e - (Y.e)^-0.076
You'll see that FACT(Z)=X quite closely !!
I've been banging my head on the walls for a while to understand why this works. Can anyone help ?

Last, CORDIC can actually calculate all transcendent functions. I think it can also be used for square roots, but don't quote me on this.


#25

You can easily calculate the inverse of the Gamma function (> 2 or whatever parameters you specify) by using the solver on the 32SII or any of the other HP calcs with a solver and the Gamma function.

With a bit of effort you can even get the solver to compute a sort-of inverse factorial function that returns the closest value on calculators that don't have a Gamma function.

Mathematica has a built-in inverse Gamma function that they "regularize", but I don't know of any calculators that have that function built-in (although I haven't checked the 49G).

-Katie

#26

Les & gang,

I'm wondering if 'Comer functions' is some little-known broad catch-all term meaning "hardware functions based on shift & add iterations".

Technically, I believe CORDIC really only generates trig functions (sin, cos, atan, maybe a few others). Log and exp use a similar shift and add method but I don't think it's really done in the 'coordinate rotation' sense.

But for practical purposes, we can say the HP calcs - at least the original ones up thru 41C/V/X,10/11/15C - use CORDIC or CORDIClike shift/add iterations to perform the main transcendentals. (We know this, it's been explained by HP and others, and we can see some code examples from ROM.)

If the author of this book is saying that shift/add iterations are not used and only manipulated table-derived functions are used, he is simply wrong, no matter who edited/reviewed the book. [Some CORDIC funcs are *slightly* table derived but only use an N-entry table per function for N digits of mantissa precision.]

As another comment, somewhat related.. back in the early 80s when I was tinkering with Commodore and other 6502-based computers, I was not too happy with arithmetic/ transcendental func performance from the ROM Microsoft BASIC. These machines used 5-byte floating point (32 bit mantissa + 1 byte exponent) for about 9+ digits of precision. (32 divided by 3.32 bits/digit). Disassembly of transcendental code showed some 'warped' (Cheybshev or other) series expansions with range reduction preprocesing and perhaps some output rescaling. As I recall, these FP functions were on average accurate to around 7+ digits except in certain key areas (near 0, 1, etc.) where things could be worse. I just never trusted these BASICs as much as I did my HP calcs. Some versions of this BASIC, IIRC, instead used 4-byte floating pt (24 bit mantissa) which was just atrocious.

Bill Wiese
San Jose, CA


Possibly Related Threads…
Thread Author Replies Views Last Post
  HP-30b discontinued? Walter B 11 3,438 09-10-2012, 11:20 PM
Last Post: Paul Dale
  48gii discontinued? David Hayden 9 2,634 05-11-2012, 05:24 PM
Last Post: Luiz C. Vieira (Brazil)
  HP 15C LE: "Discontinued" Peter Murphy (Livermore) 130 29,140 08-06-2011, 04:15 AM
Last Post: Bart (UK)
  Re: Porting 49G Programs to 49G+/50G Les Wright 0 799 02-21-2007, 10:16 AM
Last Post: Les Wright
  Porting 49G Programs to 49G+/50G Les Wright 6 2,102 02-20-2007, 06:27 PM
Last Post: Tim Wessman
  TI-57 Emulator for HP-48S/SX/G/G+/GX, HP-49G and HP-49G+ is finished HrastProgrammer 9 2,776 01-17-2006, 12:57 AM
Last Post: HrastProgrammer
  Some DigiKey batteries discontinued Mike Rivera 2 1,026 06-15-2005, 11:38 AM
Last Post: Katie Wasserman
  HP 49G vs. HP 49G+ Prices Ed Look 5 1,628 10-24-2003, 12:43 AM
Last Post: Ed Look
  HP-30S Discontinued? Tom 4 1,334 09-30-2003, 09:15 AM
Last Post: Bob
  82033 Battery Pack replacements discontinued Philip 3 1,275 08-31-2003, 04:45 AM
Last Post: Ellis Easley

Forum Jump: