▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
It will change your life to do so. Put your RPN away--force yourself to use the Formula entry model. At first, you will be so craving the RPN. You will be like, "what's with this thing!"
But at the end of the week, you will start to appreciate the positive aspects.
And then, go back to RPN. It will be like seeing an old friend----only it won't be as perfect as before....you will start to be aware of the things you could do with the formula entry.
I suggest you buy a 30s or a Casio fx-115ms......and open your mind to the other possibilites. (I got a 30s for $4.50 at staples at closeout).
RPN is a really wonderfully simple, direct, logical, consistent, robust system. Probably the simplest, mosat logical, certainly nearly most consistent (RPL even more so?) and no doubt robust. I will always appreciate that---and always find that useful.
For off-the cuff, it is really hard to beat RPN!
But the other systems have their strong points, too, and it is good for the head to do some stretching!
Best regards,
Bill
▼
Posts: 42
Threads: 5
Joined: Jan 1970
Or, get a 33s and do more in algebraic and equation mode!
▼
Posts: 177
Threads: 12
Joined: Jan 1970
I will buy several 33s's after the decimal point / comma have been re-designed to be visible. I own a 9s which is only used for dec/hex/oct/bin conversions and the the absence of a visible separator does not affect me.
Does anyone know if and when HP have plans for a revision 1?
Regards,
John
Posts: 536
Threads: 56
Joined: Jul 2005
although i find formula entry clumsy for manual calculation, there is definitely a grey area when it comes to working with formulae, solving or programming formulae.
for example, the calculator mode of the 71b is very similar to formula entry and so is the solver in the 17bii/19bii.
my main criticism of (most) formula entry calculators is not against the entry method, per se, but rather the pedantic way they insist on the usages of brackets and general lack of implied multiply colluding to waste keypresses.
▼
Posts: 887
Threads: 9
Joined: Jul 2007
There was a period when I was using the 71 and the 41 in equal amounts. The only thing I liked more about the 71 for manual-entry calculations (and still do) is that I have the math module so complex numbers are handled as easily as real. Unfortunately the 41 does not have a complex stack to compete with the 71 in that respect. Otherwise I've always liked the 41 with RPN more for the manual-entry calculations.
I used to want to learn every programming language in sight until I got into Forth in about 1990. Part of its beauty is that there's no punctuation. (Everything that looks like punctuation is actual words, as are + - * / IF THEN CONSTANT KEY TYPE etc..) I really don't care to ever return to "traditional" languages.
Posts: 785
Threads: 13
Joined: Jan 2005
Posted by hugh steers on 12 July 2004, 9:05 p.m.,
X
"my main criticism of (most) formula entry calculators is not against the entry method, per se,
but rather the pedantic way they insist on the usages of brackets and
general lack of implied multiply colluding to waste keypresses."
I like the EQW in my 49 calculator
When I press [ 5 ] [ X ]
the calc shows 5.X
I continue with [ + ] [ 2 ] [shift] [ () ]
and the calc shows 5.X+2.(<|)
where the . are in the "center" of the line
and the <| is the cursor
<< VPN >>
Posts: 97
Threads: 25
Joined: Jan 1970
I will programming my CASIO FX-850P soon. I very like that machine. That was my first pocket computer.
Cs.
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi Bill,
[Bill, what follows should be taken as a little bit of sarcasm and irony on my part, just in good humour, please I mean no offence to you or anyone else so take none, ok ?]
Bill posted:
"At first, you will be so craving the RPN"
Yes, like some crybaby craving for his/her pacifier, poor thing ! :-(
"I suggest you buy a 30s or a Casio fx-115ms"
If you're gonna commit heresy (and be thrown into RPN-hell unless repentant) you might as well do it in style. Forget about these pathetic things and get real Lexus-like quality: get a SHARP PC-1350 or PC-1475 and get to know what power and quality really means. Of course, for pure Formula Entry the one to get would be a SHARP EL-5100/5101, but that's too much for mere mortals, you must prove yourself worthwhile before deserving one of those.
"I got a 30s for $4.50 at staples at closeout"
No wonder people get to hate algebraic systems. They make do with a $4.50 crap and then complaint that it is crap and/or feels crappy. Heed my former advice and spent a little on one of those recommended models. Use any of them for a couple weeks and I dare you to say they're crap and you don't like them.
"RPN is a really wonderfully simple, direct, logical, consistent, robust system. Probably the simplest, most logical, certainly nearly most consistent [...] and no doubt robust. I will always appreciate that---and always find that useful."
Wow ! Ten adjectives in a mere two lines of text!! But you did repeat robust, simple, logical, consistent ... want me to lend you a Thesaurus so that you can attempt to cram even more in, to further make your point ? And, by the way, would you care to elaborate which of those don't apply to true, formula entry algebraic systems ? Because if they do, what's the difference ?
Also, you're preaching to the faithful, so no big deal. Try posting these same enthusiastic ramblings to any algebraic group or forum (or simply non-RPN/RPL) and see how many converts do you make and how many derogatory comments do you get as well. There's a vast majority of RPN-infidels out there that wouldn't touch RPN with a ten-feet pole, and they would probably be little sympathetic to your eloquence. That's were you should preach the RPN word ! Go for them, Bill, go for them !! Utter adjectives like mad till they see the RPN-Light !!!
"For off-the cuff, it is really hard to beat RPN!"
If you so say ... I'll take your word for it. Though you'd better not meet me in a calculating contest, lest you'd be able then to see by yourself just how hard RPN is to beat, actually.
"it is good for the head to do some stretching!"
Many RPN fanatics are such thick-headed grunts that not even a medieval torturer would be able to stretch their heads even a tiny fraction of an inch, at least not towards the non-RPN direction. :-)
Best regards from V. and if in doubt, remember my very first paragraph.
Edited: 13 July 2004, 11:41 a.m.
▼
Posts: 801
Threads: 36
Joined: Nov 2005
Hah! Humor always is grounded in some truth, somewhere...
... just yesterday, a young man objected to a solution I produced to a calculation, that I did with a 33S in RPN mode, and used his TI-89 to do it himself. Now, being a thoroughly modern neomillenial child, he very quickly and adroitly programs the calculation as a rather long formula into his multiline graphing TI, along with all the coefficients and terms and he executes it.
Wrong answer.
He tries again: same wrong answer.
I see that he botched one of the terms and so he corrects it- different wrong answer.
It turns out he had the calculation typed in 99% correctly, making ONE itty bitty term off by a factor of 10.
Yes, the 33S decimal point is a mote in HP corporate's eye, but it ain't too much better in those multiline graphing calcs, though I can't complain too much about HP's 48Gs.
But the decimal wasn't my point; my point is that while typos are more common than dirt, it is much easier to make such mistakes if you have to enter in formulae to make calculations, especially those long, tedious ones.
I use my 48Gs, too, but I use them most often as RPN machines with a humongous stack.
While I'm at it, concerning my 33S, can anyone tell me or help me to program a sorting routine for at least twenty or thirty numbers using its good old fashioned four line stack and its pleasantly new twenty-six registers? (The fewer registers used, the better!) I'm at my wit's end with this.
▼
Posts: 536
Threads: 56
Joined: Jul 2005
i have a ti-89 question. a while back a collegue of mine wound up sending his 89 back to ti because it was unable to execute the following program (dumped from the actual machine):
vwat(t)
Func
Local x
t+273.15»t
-6096.9385/t+16.635794-0.02711193*t+1.673952E–005*t*t+2.433502*ln(t)»x
e^x
EndFunc
what happened is that it printed out the above formua with `t' replaced by a number rather than reducing it to a numerical value. i tried the program in my ti89 and it worked. for some reason his refused to cooperate.
ti never replied and he lost his machine.
▼
Posts: 260
Threads: 40
Joined: Jan 1970
I did this problem on my Voyage 200 (TI-89 with QWERTY keyboard; OK I own calcs from BOTH brands):
and it did like it was supposed to. Insert a symbolic argument, you get a formula. Insert a number, you get a numerical answer.
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hi Ed,
I do not see how your story negates the value of formula entry. I see absolutely no proof in it that RPN is "better".
Rather, it merely shows that the "kid" was distracted and not as careful, practices or thorough has you.
I bet that you would have absolutely no problem getting the formula into the TI whatever--and getting it right the first time.
The fact is, if you can review the formula, then you can check it---this is not a bad thig!
The problem with the formula approach is more insidious---if you are good with actually doing computations (as we are :-) then "formula" is great.
But, if you are not experienced with doing computations--if you are not skilled in evaluating a function (and I mean manually evaluating it---observing it-feeling its terms etc) then heaven help you!
Valentin's example some days ago, with the humungous terms which tended to cancel, is a perfect example. It was a trick question, to see what happens when one blindly puts a pile of $%^% into a formula evaluator---or RPN for that matter---and pushes for an answer.
In that case, I pointed out the pitfalls of the appraoch, and the reasons why---and Werner showed the practiced, intelligent, understanding way to get to the answer.
The calculator is only a tool---and never as powerful as the brain.
regards,
Bill
▼
Posts: 536
Threads: 56
Joined: Jul 2005
apologies for being misleading. the story wasn't meant to dis formula entry, but just to point out some weirdness i encountered with the '89.
Posts: 801
Threads: 36
Joined: Nov 2005
Thanks for the comments, Bill. Oh, I wasn't really putting formula entry down; I can see its advantages when there is a more complicated expression to evaluate; I still have a Casio fx-4200P around somewhere, though it is now seldom used. But because of my personal preference for RPN/RPL, I often use pencil and paper and jot down the calculation, and then break it up into parts my mind can handle, then "RPN" each part, storing the results in registers.
I can see that the young man will blow me away with his TI-89 unless I resort to my HP-48G(+) similarly type in a formula. The problem is, I'm not at all practiced at fast-keying in formulas as the younger crowd is. I still remember when even buying RAM for my PC was not easy... wallet-wise.
And to Valentin, formulaic entry definitely has it plusses, and in the sense of time and ease of editing, it certainly is quite efficient, but to me, RPN has the efficiency of abstacting the form from paper and then using the thumb of one hand (obviously I've never had a Voyager series machine) or such to "recreate" the paper version mentally, using the RPN device as and aid. RPN does allow that to be done quite pleasurably!
Posts: 451
Threads: 107
Joined: Nov 2005
I can help with a sorting routine,
but I don't see how to save registers
since you'd need one for each number in
the list.
I assume you'd want to enter the numbers
one at a time, then review the sorted
list once you'd finished entering
the numbers?
Posts: 451
Threads: 107
Joined: Nov 2005
Hi Ed,
I posted HP33s sorting code on comp.sys.hp48
if you're interested. I tried to paste it in
here, but the result was unreadble. :)
Steve.
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
The Forum's reformatting of what you intended can be a nuisance, but see http://www.hpmuseum.org/artfmt.htm, particularly the [pre] and [/pre] codes, to see how to make things look right.
Regards,
James
▼
Posts: 451
Threads: 107
Joined: Nov 2005
Posts: 801
Threads: 36
Joined: Nov 2005
Hey Steve!
Why thanks a lot! I haven't checked the newsgroup in a while; I'll drop in there ASAP.
I truly am appreciative of your efforts!
I'll post again here after I go over there.
Posts: 801
Threads: 36
Joined: Nov 2005
Mr. Adam, I haven't looked at it nor keyed it in yet, but (and again, thanks!) at the very bottom:
... Free MEM = 29,096
I guess I'm just not trying hard enough..."
Like the average PCspeak-er would say, "LOL!"
▼
Posts: 451
Threads: 107
Joined: Nov 2005
I just realised that the list program
LBL L is unnecessary since you can step
through the list of vars using MEM Vars
Steve
▼
Posts: 42
Threads: 5
Joined: Jan 1970
I have recently posted my sorting code for the 33s to comp.sys.hp48.
All comments, suggestions, and corrections are appreciated.
Martin Cohen
▼
Posts: 42
Threads: 5
Joined: Jan 1970
(To make it easier, here is the message I posted on comp.sys.hp48)
Well, here's my sort code for the 33s. All comments (especially
corrections and improvements) are appreciated.
Martin Cohen
======================================================
HP 33s Sorting
--------------
These routines sort A..(any letter) into increasing order. The variable
i is used to hold both a current pointer (in its integer part, IP) and the number of values stored so far (in its fractional part, FP, after dividing by 100). Using (i) makes use of the fact that the 33s ignores the FP of i.
There are two routines. The core routine (label Y, also using label Z),
adds a new value to the currently sorted list. Routine label R sorts the first n values (in A to whatever), where n is the value in the X register. i must be set to zero before calling R (to save a label).
Routine Y is carefully designed to preserve the X and Y registers passed to it and leave them as they were when it returns. This allows routine R to keep the number of items to be sorted in the registers so it does not need to be stored.
You could save a label (very valuable on the 33s!) by placing the Y/Z code inside the R code where it is called.
Here are the routines.
Routine Y.
Inputs: X register: value to be inserted into sorted list.
i: IP=current pointer; FP=number in list/100
Outputs: The value is placed in the list and the list size is incremented.
The X and Y registers are as when called.
Lbl Y rcl i IP x=0? gto z // if before list start, done
Rv // value back to X
rcl (i) x<y? gto Z // if (i)<value, done
1 sto+ i Rv sto (i) Rv // store (i) into (i+1), preserving X, Y
2 sto-i // change incremented i to i-1
Rv Rv // leave the value in X
gto Y // do again
Lbl Z // value in Y reg, want to store in i+1
Rv 1.01 sto+ i Rv // value in X reg, bump i by 1.01
sto (i) // store val
rcl i FP 101 x sto i // recover i from FP, put in IP and FP
Rv // leave value in X reg
rtn // done
Routine R.
Inputs: You must set i to zero (this foolishness saves a label).
Put number of items (A to whatever) in the X register.
(I.e., to sort A through I, place 9 there).
At the end, the value should be sorted.
Lbl R rcl i x>=y? rtn // done if pointer >= number wanted
Rv // restore number to X
1 sto+ i rcl (i) // get next value
x<>y sto- i Rv // restore i and stack
XEQ Y // insert the value
Rv gto R // remove value from stack (so size to sort in X) and repeat
▼
Posts: 42
Threads: 5
Joined: Jan 1970
(To make it easier, here is the message I posted on comp.sys.hp48)
There were two errors in the code.
They are corrected here, with the lines marked with *****.
-----------------------------------------------
Well, here's my sort code for the 33s. All comments (especially
corrections and improvements) are appreciated.
Martin Cohen
======================================================
HP 33s Sorting
--------------
These routines sort A..(any letter) into increasing order. The variable
i is used to hold both a current pointer (in its integer part, IP) and the number of values stored so far (in its fractional part, FP, after dividing by 100). Using (i) makes use of the fact that the 33s ignores the FP of i.
There are two routines. The core routine (label Y, also using label Z),
adds a new value to the currently sorted list. Routine label R sorts the first n values (in A to whatever), where n is the value in the X register. i must be set to zero before calling R (to save a label).
Routine Y is carefully designed to preserve the X and Y registers passed to it and leave them as they were when it returns. This allows routine R to keep the number of items to be sorted in the registers so it does not need to be stored.
You could save a label (very valuable on the 33s!) by placing the Y/Z code inside the R code where it is called.
Here are the routines.
Routine Y.
Inputs: X register: value to be inserted into sorted list.
i: IP=current pointer; FP=number in list/100
Outputs: The value is placed in the list and the list size is incremented.
The X and Y registers are as when called.
Lbl Y rcl i IP x=0? gto z // if before list start, done
Rv // value back to X
rcl (i) x<y? gto Z // if (i)<value, done
1 sto+ i Rv sto (i) // store (i) into (i+1), preserving X, Y
***** ^ Rv removed
2 sto-i // change incremented i to i-1
Rv Rv // leave the value in X
gto Y // do again
Lbl Z // value in Y reg, want to store in i+1
Rv 1.01 sto+ i Rv // value in X reg, bump i by 1.01
sto (i) // store val
rcl i FP 101 x sto i // recover i from FP, put in IP and FP
Rv // leave value in X reg
rtn // done
Routine R.
Inputs: You must set i to zero (this foolishness saves a label).
Put number of items (A to whatever) in the X register.
(I.e., to sort A through I, place 9 there).
At the end, the value should be sorted.
Lbl R rcl i IP PSE x>=y? rtn // done if pointer >= number wanted
***** ^^^^^^ these added
Rv // restore number to X
1 sto+ i rcl (i) // get next value
x<>y sto- i Rv // restore i and stack
XEQ Y // insert the value
Rv gto R // remove value from stack (so size to sort in X) and repeat
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hi Valentin,
Thanks for the humorous feedback.
BTW, my old colleage, a German, whom I worked with in 1998, had a machine that looked very much like your Sharp models---I remember that it was a BASIC programmable----but I cannot remember whether it was a Sharp, or a Casio. Did Casio make devices similar (with the landscape layout and metal bezel) to the Sharps?
I remember that he sort of frowned or smirked when he saw my HP 32sii---his machine was certainly more powerful than mine!
On a more academic (serious) note, you asked, with regard to consistency and logic,
Quote:
And, by the way, would you care to elaborate which of those don't apply to true, formula entry algebraic systems?
Yes, indeed, there are many inconsistencies to mention. The largest inconsistency is merely that different models have different rules for basic operations.
But others are merely annoying:
HP 32sii equation list (an algebraic exression evaluator)
the +/- key is required for second arguments
of two number functions, viz %chg(200 -150)
whereas the minus operator can (or should? can't
remember!) be used in other positions.
HP business calculators, e.g. 17bii, there are parenthesis
but no precedence. However, in the solver,
parenthesis do have precedence.
Some machines do "implict multiplication" and some do not.
On the HP 33s, you can use "implicit
multiplication" in the ALG command line, but not in
the equation list.
Many "formula entry" machines have an input buffer length
limit, including both the HP 30s and the Casio
fx-115ms: 80 characters. The long expression
you posted about a week ago just barely fit in
those machines. The formula machines *without*
a recallable input buffer do not have this
problem, as they evaluate intermediate results---
but some are confusing to understand regarding
many of the functions correct actions--especially
troublesome are negatrive exponents.
There are really two major categories of "Algebraics":
1. "traditional" algebraics like the hp 20s, TI 30,
etc. These are actually postfix (like RPN) for
all "one number functions", and infix for the
arithmatic operators. Parenthesis and pending
operations are implemented.
2. "Formula Entry" algebraics, which attempt--not
always successfully--to implement "type in your
expression just like it is on paper." "DAL",
"S-VPAM" and "Formula" are some of the names
for these systems.
You will notice that I find inconsistent behavior on (gosh!)
HP machines. No manufacturer is immune to this.
The fact is that when there is an actual formula to work from--an equation or expression which is written down, the ability to put a formula into an input buffer which is recallable after evaluation, is superior to RPN. I really like RPN. It is definitely fast. But, if you can check your input, and more importantly recall it---then that is better in almost all circumstances. Except that experienced arithmeticians (is that a new word?!) find no need for recalling much of their work.
BUT--and this is important---in all my years of exclusive RPN usage, although I could trust the keypresses etc., for any calculation that mattered, I would always DO IT TWICE! Why, because if you are an engineer and not just a hack, you better be sure you get it right!
For an interesting comparison to this RPN/formula business:
When I first discovered spreadsheets, I was blown away by them. I was like, "wow!!!!!!!" And you know, most anything that I used to do on a calculator went onto the spreadsheet. Spreadsheets are especially useful for those dreadfully tedious computations that the naval architect routinely encounters: weight-moment computations. The spreadsheet makes it possible to type in all your input, check it, and get an answer.
Of course, as the size and complexity of the spreadsheet increases, it becomes dangerous. Then, a database approach becomes much more reliable.
However, through all of it, the calculator remains an indispensible tool for checking the formulas! (For instance, I used the programmability of my hp 11c to write a weight-moment program which is very handy for checking---I originally wrote it before I had a spreadsheet!).
The realy driving force behin the "Formula" calculator is memory. All of our favorite HP handhelds up until the 41c were very tight on memory. RPN was especially suited to low-memory---as very little is kept in memory!
But once you have gobs of memory available, then there is no reason why you shouldn't keep a lot of input data.
I think I am arguing strongly for the Formula design, aren't I?
In fact, I like the RPL concept of algebraic objects on an RPN stack---that is very powerful and flexible.
What makes the HP machines (up through the Pioneers) good is not so much the RPN, but rather the combination of good tactile feedback, programmability, well thought-out layout, and thorough manuals, in that order.
I am not sure that there are any keystroke programmable calculators in production now, from any other manufacturer.
Best regards,
Bill
Edited: 14 July 2004, 9:06 a.m.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Bill:
Bill posted:
"Did Casio make devices similar (with the
landscape layout and metal bezel) to the Sharps?"
Yes, but they were always of lower quality than the SHARPs. Casio was to SHARP as TI was to HP, so to speak. Your German colleague most probably had a SHARP, as they were extremely popular in Germany, much more so than in any other European country. Just have a look at eBay-Germany and you'll see the tremendous number of SHARP machines being auctioned there.
"I remember that he sort of frowned or smirked when he saw my HP 32sii---his machine was certainly more powerful than mine!"
Logical. What did you expect ? And I hope he didn't try to compare I/O capabilities, it would've been pathetic.
"Many "formula entry" machines have an input buffer length limit, including both the HP 30s and the Casio
fx-115ms: 80 characters."
Logical as well, I would change "many" for "all" or "nearly all". The HP-71B's input buffer is 96 char long, same for my SHARP PC-1350, and I remember that HP-80 series did also have some limit as well, say 96 or 120 chars. I don't see any problem with this.
As for implied multiplication, those SHARP models that were limited to just single letter variable names (A, J, Z) did allow implied multiplication, very cleverly implemented (e.g.: 2ABC => 2*A*B*C, SIN 2AB => SIN(2*A*B), AB^3 => A*B^3), while models permitting long variable names obviously disallowed it (e.g.: DISTANCE = SPEED*VELOCITY). When reading programs from a tape, long-name models would automatically convert any implied multiplications to explicit ones.
"There are really two major categories of "Algebraics": "traditional" algebraics [...]"
For me, these are hybrid-algebraic machines at best, and I want nothing to do with them. I don't like their system nor do I defend them in the least. You can trash them as much as you want, I couldn't care less. They and their capabilities never enter my arguments.
""Formula Entry" algebrtaics, which attempt--not
always successfully--to implement "type in your
expression just like it is on paper."
I would change that "just like it is on paper" to "True Algebraic", meaning that they obey all precedence rules and nestings and are strictly infix algebraic systems. They may implement a number of reasonable shortcuts such as allowing implied multiplication [2ABC => 2*A*B*C], not requiring parentheses for unary arguments [SIN 2AB + SIN 2BC => SIN(2*A*B) + SIN(2*B*C)], or closing final parentheses automatically [2*(3+5*(7+2 => 2*(3+5*(7+2))], as a typing aid, but the standard full form always works.
"You will notice that I find inconsistent behavior on (gosh!) HP machines."
You had it even easier. Just look at the HP-41C, for instance, with its STO+23, FIX 5, TONE 0. Does this seem very 'postfix' to you ? Of course it doesn't ! RPL gets it right, but at the expense of becoming unnatural and unreadable, kind of "obfuscated RPN". Only True Algebraic systems are both consistent in their use of infix operations come what may, as well as maintaining the highest readability possible.
"The fact is that when there is an actual formula to work from--an equation or expression which is written down, the ability to put a formula into
an input buffer which is recallable after evaluation, is superior to RPN. [...] if you can check your input, and
more importantly recall it---then that is better in almost all circumstances."
See ? This fact that you've been able to ponder and experience for yourself seems to be forever beyond the grasp of most die-hard RPN fanatics, and I fear that this very fact is one of the worst things you can blame RPN for: It does produce such a terrible effect on the brains of people addicted to it that they are left with a severely damaged capacity to objectively consider calc-related facts forever, not to mention the acute withdrawal syndrome they experiment if deprived of RPN even for the simplest calculation. They are 'computationally-challenged', crippled for life, another RPN victim ! What a pity. Good to see you're not one of them.
"RPN was especially suited to low-memory---as very little is kept in memroy!"
If you need 8 pending intermediate results at a given time you'll need 8 RPN registers, which is the same number of internal registers a True Algebraic system needs, period. TA systems do use more memory to hold the intermediate operators, but as they're previously tokenized, this is not significant (they usually take only a single byte each) and they're automatically discarded once evaluated. The only extra memory requirement is to keep a copy of the input buffer, so that you can recall the whole evaluated expression(s) at once, but you'll agree this is a very convenient way to use up a little memory.
As for "very little is kept in memory", when a TA system is done evaluating the expression, all internal data and operators registers are automatically emptied, thus no memory is wasted. On the other hand, the typical RPL system's stack is usually cluttered with an ever increasing number of discardable past results no longer relevant or needed, wasting memory, unless the user remembers to clear them frequently, preferably right at the end of some calculation. This is a chore, and a TA system does it automatically for you, everytime. So, which system is more memory efficient in practice ?
"I think I am arguing strongly for the Formula design, aren't I?"
Yes, your are. But it was only to be expected, as long as you're a highly intelligent individual who can think for himself and overcome obsolete topics and brain-washing, decades-old mantra-like arguments which are no longer relevant.
Welcome to the club and best regards from V.
PS: And dont't forget to try my 'HP-15C RPN Certification Exam' quiz, to be posted soon ! :-)
▼
Posts: 97
Threads: 25
Joined: Jan 1970
Valentin wrote:
"...they [CASIOs] were always of lower quality than the SHARPs. Casio was to SHARP as TI was to HP..."
I was disappointed in the "mythical" SHARP PC-1500 (in Hungary was licensed in 'PTA-4000' name), when I try to re-use my last calculation's answer. It had no 'ANS' function!!!
I think, the 'gap' is bigger between TI and HP than SHARP and CASIO. I think, the CASIO and SHARP are similar good powerful pocket computer makers, but TI is not HP ;)))
Csaba
Ps.: I'm learn English, so, I will writing more and more elevated contributions :)
▼
Posts: 204
Threads: 20
Joined: Jun 2005
Both of them made excellent machines. Think about the FX602-P, an extremely well conceived machine and one of the first, if not THE first with 5x7 dot matrix ASCII display, and thus able to display lowercase letters. I remember it made the 41C look outdated back in the 80s.
▼
Posts: 141
Threads: 29
Joined: Jan 1970
It was a technology leap. We could store program in cassette media using the i/o interface that was sold separately.
Pio
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Pio:
The very early models (SHARP PC-1211, aka TRS-80 PC1, etc) did require a dedicated cassete interface, usually bundled with a printer as well, see this link for full details and stunning pictures of it all.
But later on, you had the choice to use a dedicated micro-cassette interface (with printer) which would store hundreds of Kb worth of programs and data in extremely small microcassettes, or else buy (or build yourself) a simple cable to connect the machine to a standard, inexpensive cassette recorder (the cheaper, the better), with start/stop remote control and all.
Have a look at this extremely interesting link to see full details for a lot of cassette interfaces, cables, and peripherals for SHARP computers.
That was about the easiest, most economical way to store programs available by far. Yes, the 41C Card Reader was fancy and all, but it was outrageously expensive, and the cards themselves were not cheap either and would only store 224 bytes per card, while a single cassette tape would hold almost any amount of programs on it. Combine that with a tape counter, and you've got yourself an extremely easy and ultra-cheap mass storage capability. Programs could even MERGE other programs from
the tape, all under program control via the remote cord.
They could also read from and write data to the tape under program control, so you could have a program that would read massive amounts of data, a block at a time, process them,
then write massive amounts of results to the tape, for later inspection or further processing by another program, all of this unattended, say running it at night.
That you could not do with a 41C+Card Reader, as the cards wouldn't jump out of the cardholder by themselves, to be read/written at the prope times, you'd need to do that by hand, interactively. You would have to feed the cards, no sleeping while the machine merrily works.
HP never came with anything like that. The card reader was a good solution for the 41C, if expensive. But for the 71B, cards were nearly preposterous, inconveniently long and holding just 1.3 Kb per card, so you'd need a number of them for any significant application program, let alone to store data. You could use HP-IL and digital tape or floppy disks, but that would cost many $, and would be
inconvenient to carry around, not to mention power supply problems. On the other side, a walkman-sized cassette or microcassette would suit you fine with a SHARP.
I'm still amazed to this day that noone, be they HP or third-party, did ever offer some kind of inexpensive
interface to a standard cassete or microcassete recorder for the 41C series and/or the 71B series. They'd have sold like mad.
Best regards from V.
Edited: 16 July 2004, 5:02 a.m.
▼
Posts: 25
Threads: 9
Joined: Jan 1970
Hi Valentin,
I had the FX502+cassete interface and a FX602P. Sold all for a college friend and stepped up(?)to RPN. I still have a copy of an old PC1500 manuals. It has a color pen type print.
Greetings from Brazil
Pio
Posts: 1,792
Threads: 62
Joined: Jan 2005
Valentin posted,
Quote:
Just look at the HP-41C, for instance, with its STO+23, FIX 5, TONE 0. Does this seem very 'postfix' to you ? Of course it doesn't ! RPL gets it right, but at the expense of becoming unnatural and unreadable, kind of "obfuscated RPN".
Valentin gave three examples of what might be called "prefix commands/postfix arguments under traditional RPN".
I've never found this the least bit inconsistent. 23, 5, and 0 in these examples are not numerical operands; rather, they are simply identifiers that never enter the stack. It is certainly more intuitive to have these identifiers follow the command (e.g., Store where? How many decimal digits? Which tone?). If these were structured as postfix commands -- as they are in RPL -- the identifiers would needlessly clutter the limited stack and push actual data up and possibly off.
As for "get(ting) it right .. at the expense of becoming unnatural and unreadable..", that certainly defeats the purpose, doesn't it? But I agree with your point -- postfix for these commands is a senseless and unwise "consistency".
-- Karl
Edited: 15 July 2004, 1:10 a.m.
Posts: 68
Threads: 19
Joined: Sep 2009
Bill, if you like formula-based entry, read this!
http://thetabletpc.net/reviews.htm
|
