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 HP21...
Has the HP49G been discontinued?


« Next Oldest  Next Newest »

▼
12252002, 05:59 PM
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.
▼
12262002, 12:23 AM
The news doesn't look good; check the official HP online catalogue; http://www.shopping.hp.com/cgibin/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 !
▼
12262002, 01:01 PM
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 reverseengineer 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 softwareswitchable, 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 threeway 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. ▼
12262002, 02:59 PM
Hi..
>[Glen Kilpatrick wrote:]
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 RPNlike 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 12 Kwords of ROM. (As I recall, roughly equivalent functionality TI calcs took more ROM space than 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 higherorder 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. X86 and other CPUs with floatingpoint engines have changed design over time. The 80x87 NPU chip, and its onboard 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 Nbit register set and deliver N bits of result  instead of, say, N2 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
12262002, 03:41 PM
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 . . . ) ▼
12262002, 06:58 PM
HI; Paul, you got it! That's why they need the old manuals so badly... (Could not resist, too...)
12262002, 04:22 PM
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 readonly 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 readonly 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 quicklyconverging polynomial equivalent to other power series expansions. Best,  Les ▼
12262002, 05:23 PM
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 'howto' 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 multiROM table with some feedback.
But I'm sure that ROM tables  even with a bit of structural compression and some numeric processing tricks  [CORDIC methods typ. require an Nvalue 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 mid70s lower cost calcs due to speed and memory limitations. Some of these methods require divisions. (Though I believe some early70s nonconsumer desktops  Monroe?  may have used Chebyshev or polynomial approximations for their transcendentals.)
Bill Wiese
▼
12262002, 08:13 PM
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 HP35, 45 and 65 (as well as the SR50). In fact, the Preface states, "My thanks to the people at HewlettPackard who reviewed and critiqued the manuscript, and in particular to the HP65 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 ▼
12272002, 04:40 AM
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 20decade calculator) may be precalculated. 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 hardcoded (you can calculate at a lower precision using the same tables  see Sharp's switchable 10 or 20digit 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. ▼
12272002, 11:03 AM
Not to quibble, but my HP32S 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 noninteger 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? ▼
12272002, 02:20 PM
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 . . . )
12272002, 06:42 PM
You're 100% right, but most calculators only calculate the factorial, which is defined for nonnegative 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 : 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. ▼
12282002, 01:15 AM
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 sortof inverse factorial function that returns the closest value on calculators that don't have a Gamma function. Mathematica has a builtin inverse Gamma function that they "regularize", but I don't know of any calculators that have that function builtin (although I haven't checked the 49G). Katie
12272002, 04:01 PM
Les & gang, I'm wondering if 'Comer functions' is some littleknown broad catchall 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 tablederived 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 Nentry 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 6502based computers, I was not too happy with arithmetic/ transcendental func performance from the ROM Microsoft BASIC. These machines used 5byte 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 4byte floating pt (24 bit mantissa) which was just atrocious.
Bill Wiese
