Global Thanks & Alg/RPN/RPL Summation



#5

My Global Thanks to all for the clarification on Chebyshev polynomials. I understand that while they do converge faster than more traditional, more familiar polynomials, they aren't suited to calculators (my grad school's professorial speculations were then so much hot air :), and that CORDIC / Comer functions that give you one digit of significance per iteration are the way that was gone.

However, my other point in this Global Thanks is to recognize what I infer as a widespread Forum opinion, that we'd all be perfectly happy with an Algebraic, so long as it did RPN and/or RPL as well, that we don't require a "pure RPN" from HP, and we understand that a mixed ~OS would have much more widespread appeal (to the Great Unwashed with no knowledge of Reverse Polish _yet_ :).

And further, those of us who objected to the 49G (not all, mind you, but I'm one in the objecting camp) did so not because it was Alg/RPL, but because of what we perceived as issues of quality (the easy-scratch screen, the poor feel of the keys, the misplaced ENTER, _etc._). And while I didn't have a problem with galloping featuritis (there are many areas on my 48 that I just ignore, editing an equation is a glaring example), I recognize that many did, the 49G just wasn't a particularly easy calculator.


#6

Glen,

I agree - most of us on this forum believe strongly in the superiority of RPN. However, we don't believe in RPN so much that we'd rather see it die than combined with AOS in a hybrid.

I think there are a lot of advantages in hybrids. Perhaps previously the constraints of RAM, ROM, and clock speed prevented an economical hybrid. However, a * quality * HP hybrid could introduce a much broader range of users to a decent calculator, and perhaps even win a few RPN converts in the process (my evangelistic streak is showing).

I think it would be great for HP to introduce such a calc along with a well written tutorial comparing RPN and AOS, with some instructive examples. You know, the classic "it takes 15 keystrokes to solve this in AOS, but only 11 in RPN" or something similar.

I have only one demand if HP produces a hybrid - it must have an ENTER key in the right location. Heck, they can even call it something else, but we all know what it's for. Oh yeah, good keys, too. I guess that's two demands.

- Ed


#7

Ed,

Your mention of position of [ENTER] key is important.

I think a dual-mode RPN/AOS calc keyboard layout might be a bit compromised, perhaps for both modes!

And many of us don't give a damn about AOS. (If something like line-oriented BASIC programming were also provided, that's fine, but otherwise I want the primary nonprogrammatic interface to be RPN. And "Classic" RPN at that: 4-level stack XYZT and L register - not the funky HP48 stack.

Using [ENTER] positioned where most [=] keys are located, or placing [=] where most HP's [ENTER] keys are located, would result in operational 'weirdness' for one or other mode. Plus, [ENTER] should be larger key.

I'm really used to [ENTER][EEX][CHS][Clr] placed immediately above the numeric area. I'm used to [=] being 'down south' below the operator keys. I'm ambivalent toward position of [CHS] (or [+/-]) and [EEX] as I'm used to both.

One idea might be to have a vertically-oriented ENTER/= key down in the lower right corner area. Might be livable.

Given that HP has removable/replaceable keyboard covers in different colors, perhaps some keys could also be moved around, or spares supplied with alternate labels. The ultimate hardware-centric version of HP41's [USER] and [ASN] :)

Bill Wiese
San Jose, CA


#8

I like RPN, but I don't mind having the "equal/enter" key on the bottom right hand corner. It could be, as you stated, a long vertical key. However, there is another alternative which would serve AOS as well as RPN modes, but perhaps not EOS modes.

On many of the HP calculators that handle AOS, the long key is labelled "INPUT" rather than ENTER. In HP's AOS mode as on the 20S, this key separates operands in certain binary operations such as percentage change, combination/permutation, etc. These operations are handled as RPN dyadic operators. Both operands are entered and then the operation is selected.

On the 19BII, when the RPN mode is selected, the INPUT key reverts to the [oops] equivalent of an ENTER key for the most part. The end result in RPN mode is that you can use the "equal/enter" key or the INPUT key. The penalty is some redundancy in the RPN mode, but I don't believe this is particularly problematic. This seems to be a reasonable compromise that would satisfy both sets of users, however, I'm not sure how this affects an EOS mode, which is likely to be the alternative to RPN, rather than AOS.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Writing RPL programs on OS X Sean Freeman 18 830 11-30-2013, 03:59 PM
Last Post: Sean Freeman
  48G vs 49G+ User RPL Speed Comparison John Colvin 7 349 11-16-2013, 10:07 PM
Last Post: Han
  RPL 32 David Hayden 4 276 11-11-2013, 11:34 AM
Last Post: David Hayden
  [PRIME] RPN: another attempt at returning more than one value to the RPN stack Marcus von Cube, Germany 5 404 11-05-2013, 02:44 AM
Last Post: Marcus von Cube, Germany
  HP Prime Error: Summation Upper Bound > 1000 HP Pioneer 2 199 10-25-2013, 11:32 AM
Last Post: steindid
  HHC / HP Museum Programming Contest for RPN and RPL machines Gene Wright 18 809 09-22-2013, 09:39 AM
Last Post: Miguel Toro
  [WP 34s] Summation Function (Sigma) Paul C 11 466 01-29-2013, 07:42 AM
Last Post: C.Ret
  HP 34s summation question Richard Berler 3 185 01-01-2013, 02:54 AM
Last Post: Thomas Klemm
  RPL long vs. short names peacecalc 5 287 10-30-2012, 01:25 PM
Last Post: peacecalc
  Mini-challenge: HHC2012 RPL programming contest with larger input David Hayden 14 633 10-05-2012, 10:36 PM
Last Post: David Hayden

Forum Jump: