▼
Posts: 126
Threads: 19
Joined: Jan 2012
In reference to my petition at hp15c.org, someone sent me this message;
Quote:
Well, I am working for TI in the calculator division and interested to know what is special about HP calculators and why you want HP back [rather] th[a]n using TI.
That is a loaded question, how would you answer it?
Chris W
▼
Posts: 785
Threads: 13
Joined: Jan 2005
Because they have thet big ENTER key and RPN logic.
Also the keyboard click reponse has been excellent.
The conservative color and overall design pleases eye and hand.
(VPN)
Posts: 182
Threads: 17
Joined: Oct 2005
Chris, I leave it to your decision whether or not you pass my message to the gentleman in question.
"On his site the author has justified why he thinks the HP15C is the best calculator for every day (engineering) work. I think that the device is indeed a very good optimum between size, usability, functionality, programming power, power consumption and layout. For other tasks and/or other places people may think differently, but apparently the author estimated that a "new" HP15C very well could fill a gap in the calculator market. And therefore he set up the petition to find out.
And to be very specific about why not TI: RPN. Perhaps a matter of taste, but that's just THE difference."
Posts: 155
Threads: 5
Joined: Jan 1970
I guess I wouldn't. It's probably someone yanking your chain. Even if it has a TI address and someone responds, it's probably a new low level employee who hasn't read the corporate Internet guidelines yet.
Posts: 308
Threads: 26
Joined: Jul 2007
Chris...
Quote: Well, I am working for TI in the calculator division and interested to know what is special about HP calculators and why you want HP back [rather] th[a]n using TI.
He's probably wondering why there's a whole site devoted to old HP calcs in such detail. This guy may not be a really 'useful' contact as far as changing direction of calc market but may be a curious guy simply wanting 'enlightenment'. Perhaps a few comments from him may make it up the pipeline, who knows??
So I'd tell him this:
Quote:
The primary thing that separates all older HP calcs (those of the 1970s1980s with a couple from earlytomid '90s) from TI (and other) calcs is their use of "traditional RPN".
Many of us HP do not consider RPL calculators with an 'infinite stack'  like today's HP48/49 series  to be true RPN devices.
"Traditional RPN" uses a 4level stack with Tcopy down and a LastX register. It's combined with a favorable keyboard layout for ease of use, having a _large_ ENTER key above or on the side of the numeric area. (This is one reason why many purchasers of the new HP33S dislike this calculator, besides its annoying 'chevron' keypad layout.)
This system makes doing calculations while 'thinking on the keyboard' quite easy and graceful. No worries about parentheses closure, etc. And unlike formulaentry calculators common today, intermediate results are continually visible as a sanity check. It may take about a day for an AOS calculator user to become accustomed to an RPN calculator  can't be too hard, I learned how in middle school while at the huge HP display in Macy's.
Here's a quick example: evaluate the polynomial
5x^5  6x^4 + 7x^3  8x^2 + 9x  10
for x=1.2345
On an HP traditional RPN calc:
1.2345 [ENTER][ENTER][ENTER]
5 [X]
6 [][X]
7 [+][X]
8 [][X]
9 [+][X]
10 []
which returns 2.48877... Here, we used Horner's method to great advantage with RPN and the Tcopydown feature. Doing Horner's on an AOS TI calc would get me lost in a sea of parentheses  I'd be better off resorting to using powers of X.
In addition to ease of operation, such older HP calcs had sturdy frames/casings, had clear, legible LCD displays with wide viewing angles, and had excellent keyboard characteristics: "click" keys that were fully debounced  no false entries or 'doubling' of keystrokes. There was just an overall impression of durability and quality, combined with excellent humanfactors engineering (pocketability, battery life, and overall "feel").
The programmable HP calcs also offered graceful keystroke programming that let users quickly set up in essence a custom calculator for repeated tasks.
HP was also known for the excellence in their internal algorithms and excellent QC. (Sadly, this 'edge' no longer seems to be present.) The Solver and Integrator algorithms in the HP34C, HP15C and the related TVM financial functions that used the solver on the HP12C were designed with the assistance of Dr. William Kahan of UC Berkeley, who's kind of the "god" of graceful floatingpoint math and related issues.
By contrast, many TI calcs of late 70searly 80s were released w/errors in them, especially in the basic multiplication algorithm!! While not always noticeable in a single calculation, this was compounded in log and trig functions that used repeated multiplications. For a very good detailed anaylsis of these errors, see:
http://www.vcalc.net/tiaccry.htm
As the TI calculator market seems to be schoolteacherdriven, it has avoided the people who do real math with real calculators. And yet the highend TI calcs (like TI89) offer so much complexity that those of us needing to perform that kind of 'big problem' math work instead turn to desktop PC applications like Matlab, MathCad, Excel or custom C programs.
That's my two bits...
Bill Wiese
San Jose CA
▼
Posts: 15
Threads: 2
Joined: Jan 1970
If you do want to reply, you may want to point out that the 15C is keystroke programmable. This is something that none of the current TI models offer.
Posts: 901
Threads: 113
Joined: Jun 2007
Let us suppose that the question is an honest attempt to understand why HP afficianados won't buy TI machines. If so, then "RPN" really isn't an adequate answer. The attachment to the HP product line is as much mystical as it is rational, and at times seems to be quasireligious. In a sense the HP adherents are like a cult when they describe their machines with words and phrases such as "sleek lines", "sleek efficiency", "overall feel", "design pleasing to eye and hand", and the like. Some of these guys even write paeans to their machines!
One of the salient characteristics of a cult is a tendency to belittle others. In my engineering school days back in the late 1940's one cult included the owners of K&E slide rules. No owner of a K&E Log Log Duplex Decitrig would ever entertain, even for a moment, that a Pickett or a Post could be quite as good. Owners of HP calculators with RPN logic have described the users of AOS machines as "the dark side". The cult of users of TI calculators with AOS logic responded to the "dark side" appellation by noting that RPN was really an acronym for Really Pathetic Notation. Members of the Apple computer cult insisted on calling the Radio Shack TRS80 product line "Trash 80's."
Another characteristic of a cult is that it's members develop dogma which is intolerant of dissent. For HP users one such article of faith is that RPN provides a superior way to evaluate the Mach Number equation which appears on the cover of the manuals for the HP67 and HP97. But, Bill Wozniak, the coinventor of the Apple computer, has described a situation when he was working at HP in which he demonstrated the ease with which a TI machine could solve the problem and wrote "My colleagues couldn't believe it. I told them that you just copy the formula from left to right but not one of them could see through their postfix fog. After all, these were the calculator experts of the world. They are well accustomed to thinking ahead and analyzing an expression to come up with the order of steps to take on an HP postfix calculator, and they had to remember which subexpressions were in what order on the calculator's stack. None of them could do what I had done, forget that they have to be smart." The really curious thing about the Mach Number problem is that it was at the exact level of complexity that could be solved by the least capable calculator in TI's stable of AOS machines at the time, the TI30.
There are expressions which are more easily evaluated with an RPN machine. The polynomial problem in Bill Wiese's response is one example, although I would be the first to admit that there probably are members of the TI cult who would never admit that. But there is more to a calculating machine than whether it is RPN or AOS. Bill Wiese mentions Professor Kahan of the University of California at Berkeley in his response. Professor Kahan's paper "Mathematics Written in Sand" noted that the TI59 had deficiencies in implementation including multiplication which was not commutative. The paper presented a number of sample calculations for which the HP product line yielded better results than could be obtained with a TI59. Near the end of his paper he presented an example of the inversion of a 4x4 matrix on the HP15. He did not present the results for the TI59. I wondered about that. I did the inversion on my TI59. With all its computational warts the TI59 yielded errors in the solution which were a factor of 400 smaller than those reported for the HP15. That's the kind of result that ought to cause a cult member to reexamine his prejudices, even if just a little bit.
So, I suggest that the best answer to the request is simply "It's a cult thing."
▼
Posts: 308
Threads: 26
Joined: Jul 2007
Hi Palmer,
Wow, I recall seeing your name  along with Maurice Swinnen's  YEARS ago when I was in HS, reading a friend's issue of PPC Notes.
Background: got a TI58 for Christmas in 1977  folks wouldn't buy me one of those 'weird' HPs. The TI58 was an 'accident', since my dad had gotten me a Commodore PR100 from Mr Calculator in Palo Alto but it had a misprinted/ poor quality manual and its NiCds wouldn't hold a charge.
Even then I drooled over HPs and would play with the various HPs (incl. 29C and 67) displayed at Macys. Pops got bullied into TI AOS logic because he read somewhere that TI had partnered with the Air Force Academy engineering program, and thought of that as "a good thing".
Plus the TI58 was featureladed with the Master Library, so that was quite cool.
Enjoyed spending summer of 1980? writing "big factorial" programs etc. on TI58. Enjoyed the 58 but lack of cont. memory was a hassle! So anyway I was quite comfortable in AOS or RPN. But once I 'clicked' with RPN, it made AOS seem (generally) funky for "thinking on the keyboard" calculations. In Dec 81 when I got my HP41C I was in hog heaven: RPN, continuous memory, alpha display, etc.
But, yes, at the programming level  i.e, noninteractive onetime program entry  it wouldn't make too much difference to me.
In fact, it would be entirely rational, IMHO, to have a calc that used 'expression programming', something like a BASIC, etc. for stored programs but RPN for interactive keyboard calculations. I know that's a bit of stylistic & implementation dichotomy but "it works for me". While keystroke programming was handy for quick smaller programs, larger complex programs could perhaps be a bit more sanely implemented (or at least documented) w/expressions. (Though memory constraits of yore might mitigate against this dual implementation  but HP41 had 12Kx10 of main ROM and some of the Sharp/Casio handheld BASIC calcs had 8K ROM.
I was rather disappointed that the HP71B machine didn't have an RPN calc frontend (without some kinda 41 emulation module, etc.) That would've been a fun machine!
Bill Wiese
San Jose CA
▼
Posts: 785
Threads: 13
Joined: Jan 2005
"I was rather disappointed that the HP71B machine didn't have an RPN calc frontend
(without some kinda 41 emulation module, etc.)
That would've been a fun machine!"
Well  you could have an 41TRANSlation module in your 71B
(VPN)
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hi Bill,
I agree with you that having expressions in programs makes for an easier read.
To elaborate on a tangent, in fact, that is one of the differences between RPN and RPL. RPL will handle expressions. However, the other major difference between RPN and RPL is that RPN is really a "machine code" whereas RPL is essentially a "highlevel" language (Note that Valentin has made this point before but in regards to the 71b).
For myself, however, there is an awful steep learning curve for the 48 series which I have been slow to climband so I really have not gone anywhere near using its powers, and so I stick with the old keystroke approach most of the time.
But the only real reason for my reluctance with the 48 is time and age: I am not a college kid, I already have proficiency with a different tool, I don't really need an advanced calculator, and so I am "skipping" it. A young student may make a different choice.
That is not to say I don't try to use the 48 once in a while for programming. But usually is is for programs which are very close to an RPN implemetation.
The 32sii
Best regards,
Bill N3LPX
p.s. tnx 4 ur email 3 wks past
Posts: 887
Threads: 9
Joined: Jul 2007
Bill wrote: "I was rather disappointed that the HP71B machine didn't have an RPN calc frontend (without some kinda 41 emulation module, etc.) That would've been a fun machine!"
There was a module to do that. I never got it, which may be why, when I want a calculator, I always reach for my 41cx instead of my vastly more powerful 71. I don't like the algebraic equation entry on the 71, even though "calc" mode does give you intermediate results, and a backspace undoes the last keystroke even if it was an operation.
Posts: 1,755
Threads: 112
Joined: Jan 2005
Palmer wrote:
"Another characteristic of a cult is that it's members develop dogma which is intolerant of dissent. For HP users one such article of faith is that
RPN provides a superior way to evaluate the Mach Number equation which appears on the cover of the manuals for the HP67 and HP97."
I absolutely agree with all your arguments and rationale, but this reference to Mach Number immediately prompted me to contribute to this thread. Please have a look at this archived post of mine where I thoroughly debunk the alleged "superiority" of HP machines for that particular computation:
Mach number  RPN vs. Algebraic
Matter of fact, I think that not only isn't RPN "superior" when confronted with said mathematical computation, but actually it's just about one of the worst examples to try.
Best regards from V.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hi Valentin,
I wonder what you think of the other thing Palmer mentioned: regarding "inversion of a 4 x 4 matrix with the Ti59 having smaller errors than those found in the results obtained with an HP15c.
Regards,
Bill
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Bill:
Bill posted:
"I wonder what you think of the other thing Palmer mentioned: regarding "inversion of a 4 x 4 matrix with the Ti59 having smaller errors than those found in the results obtained with an HP15c."
I'd need more data before committing to a definite opinion,
such as the contents of the matrix being inverted, what
the alleged result was for the 15C, what the alleged result was for the TI, and how was the inversion performed.
For instance, you can invert a matrix in the HP15C in four different ways, at least, and all of them differ in the accuracy obtained. Also, did the TI model have some microcoded inversion functionality, or was the inversion done by using some program, in which case I would need to be able to analyze said program's algorithm and implementation.
As you can see, making some vague statements leads nowhere as far as analyzing accuracy is concerned. Let's see some hard data and some concrete methodology and we can talk.
Best regards from V.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hi again,
It is, as I rather suspected, that the "devil is in the details"!
Regards,
Bill
▼
Posts: 122
Threads: 18
Joined: Jul 2005
It is very likely that the said matrix inversion on the TI was performed using a program in the Math Library Module. No machine language there, and thus no improved accuracy.
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi Valentin, guys;
I agree with GE(France): I also guess that Palmer O. Hanson Jr. have probably used the existing Master Library Module features([2nd][Pgm] 02), which include matrix inversion, determinant and simultaneous equations.
I have the QRG (Portuguese) and the reference for this program (ML02) has three notes, being the first one: (translated)
"Because of rounding errors, this program may give inaccurate answers for A. For example,  3 2
9 6 returns 9×10 ^{12} instead of zero".
I know the subject refers to inversion of a 4×4 and not the determinant, but if the algorithm is predicted to "fail" (be inaccurate) under certain circumstances, I perfectly understand Valentin's concerns about the program itself.
The contents of the Master Library Module can be uploaded to the HP58/59 main memory and be inspected, listed and/or altered, meaning the programs are not made "private". As Palmer does not mention the need of writing or loading a particular program, it is more likely that this library has been used, and knowing what is done is a matter of finding the (big amount of) spare time enough to "delve into".
Any volunteers?
Cheers.
Luiz (Brazil)
P.S. Valentin, I'm expecting to have two Douglas Adams originals probably in August d8^); thanks!
Edited: 28 June 2004, 11:46 p.m.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
You quoted from the instrucions for the ML02 program in the TI59 Master Library as follows:
"Because of rounding errors, this program may give inaccurate answers for A. For example,
 3 2
9 6
returns 9×1012 instead of zero".
I know the subject refers to inversion of a 4×4 and not the determinant, but if the algorithm is predicted to "fail" (be inaccurate) under certain circumstances, I perfectly understand Valentin's concerns about the program itself.
Before you get too concerned about the the admitted errors which may occur with the determinant calculation in the ML02 program you might want to look at the results from determinant calculations with other programs on other calculators. Let's use the 5x5 matrix which appears on page 14 of the manual for the HP41C Math Pac:
6 3 2 2 3
1 4 3 4 2
2 3 1 2 9
4 3 0 2 1
3 5 6 6 2
The demonstration on that page enters the matrix, solves for the determinant and shows that the answer will be displayed as 200.0000 where 200 is the correct answer. Somehow, the calculator got into the Fix 4 mode. If you switch to the Fix 9 mode you will find that the answer that is in the X register is 200.0000009 ! The results for the determinant result from several machines and programs follow in order of improving accuracy:
200.0000009 HP41 Math Pac  10 digit machine
200.0000002 HP41 Advantage Module  10 digit machine
199.9999999976 TI59 Master Library ML02  13 digit machine with warts
199.999999999 HP28S  12 digit machine
200.00000000011 TI85  14 digit machine
Is that telling you anything?
The displays of the TI59 and TI85, like the display of the HP41 Math Pac with the HP41 in Fix 4, indicate that the answer is 200, when the actual value inside the machine is in error by a small amount.
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hello, Palmer;
thank you for your comments.
I'm far from being the one to discuss such subjects. I'm an electrical engineer, I'm a teacher, and for some particular cases where engineering demands deep accuracy, four to five significant digits are more than adequate.
I am also aware of accumulated rounding errors that in exponential computations may  and will  meet these four to five digits. At the same time where processors that can easily hold floating point, doubleprecision numbers with 32digit mantissa (and even more) in portable computing devices like calculators (I am talking about their resident O.S., not an actual floatingpoint processor) or PDA's without speeding them down too much, we are discussing valid subjects like 12, 13 and 15digit mantissa calculator precision. I'm mentioning these facts just as a reference.
Except for both HP41 and TI58/59 that need extra SW to accomplish the task, either the HP15C or the HP28S have their microcode for matrices arithmetic. And in their case, I take the number handling as a result of R&D where many aspects must be balanced: ROM size and addressing, available RAM to hold temporary, input and output data, etc. I am not sure about this, but I'd not compare any of these two (15 and 28) to the others (41 and 58/59) because they deal with matrices all the time with internal precision, while in the 41 and 58/59 there are temporary results being used over and over. Also, knowing that the TI58/59 shows a 13digit display against a 10digit LCD in the HP41 is something that must be considered. I know that the HP41 computes 12digit mantissa numbers while in microcode, but I don't know how do numbers are held by the TI58/59 functions. Are they also 13digit or more?
Because of all of these facts (not because ones are RPN and others are AOS), I can only think that numbers are handled differently in both systems, having # of digits as a reference. If the TI58/59 display shows 13digits mantissa all the time, adding extra loops and higher precision results (and consequently extra terms in series that obtain inverses, logarithms, trigs, etc.) seems to be a natural, clever solution. The TI58/59 are fast for LEDbased calculators, they have internal parallel bus instead of serial bus (HP41 RAM/ROM access) and their O.S. deals only with number "crunching" and fixed RAM addresses (the HP41 has valid argument checking, XROM addressing, extended RAM and mapped I/O ports). I guess that considering the main significant digits as twelve for internal and ten for external in the HP41 architecture is related to a balance between speed, accuracy and user needs.
I did not mention numbers and precision here because both 1) there is a lot to be told about and 2) I have no skills to go further.
I thank you again for your valid information. As you mentioned that you needed accuracy in solving matrices, I agree with the fact that in some circumstances there's a need for more than a 5digit mantissa. And in these cases, whatever you use to accomplish your needs is the tool you need to use.
I hope my text is not too confusing; sorry. Sometimes I know what I want to say, and not all the times I am able to express my thoughts in English as I'd like too... d8^)
Cheers.
Luiz (Brazil)
Edited: 29 June 2004, 5:51 p.m.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
Some of the things you may be interested to know about the TI59 are:
1. It calculates with 13 digit mantissas and stores results with 13 digit mantissas. It has a ten digit display.
2. It does not have a guard digit used for rounding in the sense that the HP units do. It truncates rather than rounds results to 13 digits.
3. It has, as do earlier TI machines such as the SR52, a curious multiply algorithm such that multiplication is not commutative. Thus, e x pi is not equal to pi x e by a little bit. TI's claim was that the machines delivered results which were correct to ten digits. I'm not sure that was always so.
4. TI eliminated the noncommutative multiply starting with the TI66 (or maybe it was the TI55II).
5. TI switched to a conventional guard bit with rounding starting with the TI95 (or maybe it was the TI68).
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi, Palmer;
I own a TI59 with a PC100C and I wrote wrongly: when I wrote "shows 13 digits" or the like, please read "allows 13digit printing". Sorry about that...
I was not aware of these facts; thanks again. About the fifth item:
Quote: 5. TI switched to a conventional guard bit with rounding starting with the TI95 (or maybe it was the TI68).
Any particular reason?
BTW: my first calculator, the one I had when I went to tghe university, was a TI57. I remember it well: 8 registers, 50 (not 49) program steps, LBL with GTO and SBR. I learnt how to program with that little fellow.
Cheers.
Luiz (Brazil)
▼
Posts: 901
Threads: 113
Joined: Jun 2007
I suspect that TI switched to the more conventional guard bit with rounding format because of pressures such as those enunciated in Kahan's paper. I suspect that they dragged their feet to avoid looking like they were copying HP.
Conversely, I suspect that HP dragged their feet on switching to a longer mantissa to avoid looking like they were copying TI.
Both companies did strange things over the years. One of TI's worst was the new keyboard when they came out with the TI55II, TI57LCD, and BA55. It was so bad that when they finally fixed it and came out with a TI55III you could send in a TI55II and get a TI55III in the return mail, no questions asked. The same keyboard was used on the TI88, which was to be TI's answer to the HP41, but which didn't go to production.
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Yeap, you're right.
About HP, the "new family" (Kinpo) ones speak for themselves...
Cheers.
Luiz (Brazil)
Posts: 785
Threads: 13
Joined: Jan 2005
"
6 3 2 2 3
1 4 3 4 2
2 3 1 2 9
4 3 0 2 1
3 5 6 6 2
"
on a HP 49 series this is exactly 200
or 200. is you do >NUM first
`VPN`
▼
Posts: 44
Threads: 0
Joined: Jan 1970
Hi VPN.
In exact mode, that is not surprising.
In approx mode, the algorithm checks the matrix; if all
its elements are integers, then the determinant must be integer as well  and the result will be rounded to the
nearest integer. This was already present in the 48G (not in the 48S)
Cheers, Werner
Posts: 126
Threads: 19
Joined: Jan 2012
Quote:
[. . .]this reference to Mach Number immediately prompted me to contribute[. . .]
I have seen this Mach Number formula used both to argue how RPN is better and how RPN is more, or too, difficult. These arguments are like a religious man trying to prove the existence of God and a scientist trying to disprove the existence of God, both obviously have a fundamental lack of understanding of religion or science or both. I agree that the example is dated, and no longer applies to modern calculators, RPN or not. However, this formula is not difficult with RPN or any other calculator that has the ability to evaluate it. I suspect any scientific calculator built in the last 15 or 20 years has that ability. If you know how to use your calculator the Mach Number formula is easy to do on any scientific calculator.
As for the argument of the "so called" limitation of the 4 level stack on the traditional RPN calculators, I am still waiting for someone to show me a real world formula that can not be solved with a 4 level stack. The Mach Number formula can easily be solved using 3 levels, to use more than 4 levels would require an absurd level of incompetence.
Before calculators had the memory and processing power to evaluate and convert algebraic entry to RPN to calculate it, RPN was the only way to calculate complex formulas. (I hope everyone by now does realize that any computational device that accepts algebraic entry, converts that entry to RPN before it can perform the calculation)
RPN is the more natural way to do calculations, it is exactly the way you would perform a calculation if you didn't have a calculator. The only reason some people "believe" RPN is less natural than algebraic entry is because that is the way they have always used a calculator. Algebraic notation is, as it's name suggests, for doing algebra. Algebra is not what I use a calculator for, it's called a Calculator, not an Algebrator. I doubt that many people outside of college use a calculator for algebra either.
My point is that IF you are doing CALCULATIONS, RPN is the more natural, faster and easier method. However IF you are analyzing, studying, or trying to understand the relationship between variables in an equation, algebraic notation is useful, and if you find it necessary to do such things on a calculator, HP has made calculators that have give you that ability without sacrificing the best way to do calculations. As for myself, since I am no longer in college, I find my desktop computer, with it's large screen, mouse and keyboard a much better tool for that type of work.
Chris W
The above opinions are those of the poster, and may not be shared by the readers, but they should be ;)
▼
Posts: 785
Threads: 13
Joined: Jan 2005
[pre]
"These arguments are like a religious man trying to prove
the existence of God and a scientist trying to disprove
the existence of God, both obviously have a fundamental
lack of understanding of religion or science or both."
X
Well then there are religious scientists, too!
AND
some people find it very useful to have Algebraic Equations
in their HP32/33 or 48/49
(VPN)
PS: I swing both ways in science/religious RPN/ALG,
but otherwise I'm straight ;)
▼
Posts: 126
Threads: 19
Joined: Jan 2012
I wasn't saying that being a religious and being a scientist are mutually exclusive, just that a religious person and or a scientist attempting to prove or disprove the existence of God, didn't understand either science or religion.
Chris W
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
I found myself the other day, unexpectedly having to defend the theory of evolution.....and the person (a coworker from another office) had presented a puzzle regarding the chances of a "single celled organizm" evolvingwhich he assessed (without proof) to be essentially zero. So I constructed an adhoc analysis of probabilities, taking care to mention that the chance of our earth being in the right location cannot be taken by itself, but rather must be assessed against all of the history of spacetime (which of course dramatically improves our chances to exist!) etc etc. (no numbers involved and no true calculationsjust an assessment of the "boundary conditions").
And of course somewhere in there the concept of intelligence, reason, etc had to be developedthe big bone of contention for this other fellow was the "apeman" etc. And so of course this brought up consciousness, or the existence of selfawarenesss, to which I asked rhetorically, "so when you die, does your consciousness just go **poof! Yes, why notdo we presume to keep existing? Do we remember being asleep under Sodium Pentathol at the dentist's office?"
So of course this really did not make any progress.....in the end he asked, "so, which are you, atheist, or agnostic." To which I replied, "Christian." And so he replied that now his head is really spinning.
Religious belief is hollow if one cannot ask hard questions, if one cannot challenge the very existence of one's own faith. If faith is true, then why should one be afraid to ask? Fear of the challenge is an admittance that the faith may be untrue.
So, this applies to RPN as well. If you take "on faith" that RPN is better, but you are unwilling to test it, then your "faith" is "untrue."
Best regards,
Bill
▼
Posts: 785
Threads: 13
Joined: Jan 2005
There are many types of Christians
SOme of them don't take the beginning eg. creation literally.
Others feel that evolution is unfounded illusion based on circular thinking and "proofs" AND denial of God
It his light I see the TI vs HP, ALG vs RPN, PC vs Mac, Amiga vs Atari, Palm vs WinCE, Windows vs Linux, etc...
* unresolved *
<< VPN >>
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Chris:
Chris posted:
"RPN is the more natural way to do calculations, it is exactly the way you would perform a calculation if you didn't have a calculator."
Here you are, yet another instance of one of the most diehard RPN myths: "the way you would perform a calculation if you didn't have a calculator." ...
I don't know about you but in my case, and I suspect many other people would concur, one of the most frequent calculations I usually have to do by hand is when I'm given a 10 or 12long list of numbers (say at a restaurant) and must add them all up on the fly.
If your RPN myth would apply, then I should (either using paper or mentally) put the first number down, then the second one just below it, add them up, notice the (unwanted) intermediate result, then put the third number below it, add them up, notice the new (unwanted) intermediate result, and so on till the last number, which would be added up as well, to get the (wanted) final result.
This is exactly as you would do with your RPN calc, right ?
This is "exactly the way you would perform a calculation" by hand, right ?
Nonsense. The way I proceed "by hand" with that long list of numbers is like this: beginning from the right, I add up all singledigit numbers of the rightmost column, to get the rightmost digit of the result, plus a carry. I then proceed with the second column from the right, likewise, adding the carry, and thus getting the second rightmost digit of the result, and so on till I get the last, leftmost digit of the result.
That's the *natural* way to do it, that's how most of us do it, and nowhere in sight is your "natural" RPN method, nor do you get to see *any* intermediate results, which by the way, you don't want or need at all. You just get the final result, take out the cash from your wallet, plus a generous tip, and give it to the maître, right ?
So much for your myth of RPN being "exactly the way you would perform a calculation".
"The only reason some people "believe" RPN is less natural than algebraic entry is because that is the way they have always used a calculator."
Not my case. I began using calculators with a classic RPN HP25, never had any other calculator before. So RPN should be engraved in my mind as if casted by a red hot iron. No such thing, at all. I'm as proficient in RPN as the best of you, yet it's clear to me that any commandline true algebraic calculator can run rings around it in versatility, speed and ease of use. The fact that RPN was "the way" I learned never blinded my mind nor my objective judgment to other better possibilities.
"Algebraic notation is, as it's name suggests, for doing algebra. Algebra is not what I use a calculator for, it's called a Calculator, not an Algebrator."
That's plain nonsense and doesn't deserve any kind of answer, you're simply indulging in silly wordgames. I'd certainly expect something more rational and articulate from you.
"My point is that IF you are doing CALCULATIONS, RPN is the more natural, faster and easier method."
Your point is quite respectable but it's nothing but that, your point, a mere opinion. Unless you're able to substantiate it with objective, neutral tests and evaluations, it doesn't hold any water.
The problem with most RPN addicts (and I'm not saying you are one) is that they only know one of the sides, the RPN side. They've never taken any time to really get to know in depth, use, and explore the limits of algebraic machines. They positively dislike the very thought of doing so, and are extremely reluctant to even try. Algebraic machines are 'disgusting' to them, and not using RPN brings kind of an abstinence syndrome.
Fortunately I know both sides inside and out, and can't be fooled with RPN myths anymore. They were hard facts for a time, circa 1980 or so. They're myths ever since, and nowadays RPN is plain and simply obsolete. If you're good at it, more power to you, it will serve you well. But rest assured that anyone with a modern true algebraic machine can run rings around you with utmost ease.
"The above opinions are those of the poster, and may not be shared by the readers, but they should be ;) "
You'd better take a sit, it'll be a long, long wait.
Best regards from V.
▼
Posts: 785
Threads: 13
Joined: Jan 2005
Cris:
"The above opinions are those of the poster, and may not be shared by the readers, but they should be ;) "
You'd better take a sit, it'll be a long, long wait.
Best regards from V.
The wait is over...was it so long?
(My PC was offline: I changed the Motherboard)
(VPN)
Posts: 126
Threads: 19
Joined: Jan 2012
Quote:
I don't know about you but in my case, and I suspect many other people would concur, one of the most frequent calculations I usually have to do by hand is when I'm given a 10 or 12long list of numbers (say at a restaurant) and must add them all up on the fly.
This is a case of not seeing the forest through all the trees. You are getting too caught up in the minute details and forgetting the basic concept of post fix notation. I will concede that my use of the word "exactly" was improper. However, I still submit that it is not a myth that RPN is an electronic implementation of how you perform calculations by hand. It will take a much better example than the one you gave to prove it is.
Quote:
I'm as proficient in RPN as the best of you, yet it's clear to me that any commandline true algebraic calculator can run rings around it in versatility, speed and ease of use.
That is a very tall claim. I would like to see a few real world examples of how you can run rings around RPN in speed and versatility. As for ease of use, I keep hearing people talking about having to analyze an equation and develop a plan of attack in order to use RPN. That is nonsense, you just work from the inside out, with an equation written in standard form it is trivial to find where to start because it visually draws your attention to the inside.
Chris W
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi again, Chris:
Chris posted:
"I still submit that it is not a myth that RPN is an
electronic implementation of how you perform calculations by hand. It will take a much better example than the one you gave to prove it is."
Please explain why my example is deemed not adequate by you.
Do you use a different procedure to add up a column of numbers by hand, at a restaurant for example ? How exactly do you do it, then ? Do you add them up like you would with an RPN calculator ? If not, and particularly if you do it exactly like I described, please explain why my example is no good for you. The only way to provide a better example is if you first explain why the present one doesn't measure up, don't you think ?
"That is a very tall claim. I would like to see a few real world examples of how you can run rings around RPN in speed and versatility.
The one and only way, in my vast experience, is for me and you to meet in person, and let you see with your very own eyes what I'm talking about, when confronted with a variety of examples theoretic or from real life. Nothing else would make a dent in your convictions, only hard facts face to face. Any number of examples I could give in writing are going to be useless, only a personal demonstration would do.
"As for ease of
use, I keep hearing people talking about having to analyze an equation and develop a plan of attack in order to use RPN. That is nonsense, you just
work from the inside out, with an equation written in standard form it is trivial to find where to start because it visually draws your attention to the
inside.
Ok, try this one, written exactly as it appears on an engineering book:
((8.8+3.2)*(8.6+7.9)+(5.1+4.1)*(4.7+2.1))*((6.2+4.4)*(1.39.5)+(6.33.2)*(2.45.7))
Any of my SHARP calculators, even the simplest, will acept
me to key it in exactly as written:
((8.8+3.2)*(8.6+7.9)+(5.1+4.1)*(4.7+2.1))*((6.2+4.4)*(1.39.5)+(6.33.2)*(2.45.7)) [ENTER]
and will instantly return the *final* result (not the intermediate garbage).
Now be a sport, and first evaluate that expression using RPN, then (and only then) answer the following questions:
... spoiler space ...
... spoiler space ...
... spoiler space ...
... spoiler space ...
... spoiler space ...
... spoiler space ...
... spoiler space ...
... spoiler space ...
Questions:
 Did you get it correctly first time ? (8816.232)
I did, in seconds.
 Did you have to quickly scan the expression to see where to begin ? I didn't, just keyed it in exactly as written
 Did you have to think if 4 levels would suffice and anyway stored some intermediate values in registers, just in case ? I didn't.
 Assuming you now need to change that 7.9 in midexpression to 9.7, did you have to repeat the entire
calculation from scratch ? I didn't, I just recalled the whole expression to the display with a single key, then placed the cursor over 7.9 and keyed in 9.7, then [ENTER]. The new result appeared instantaneously, no extra retyping needed, at all. What about you ?
Anyway, Chris, I don't want to proselitize. You can think, use, and believe whatever you want as far as I'm concerned. You want to believe RPN is better ? Good for you, you have my blessings. If you feel happier thinking so I'm glad you do, period.
Best regards from V.
Edited: 29 June 2004, 12:23 p.m.
▼
Posts: 887
Threads: 9
Joined: Jul 2007
I think what Chris was referring to was when you have more levels of parentheses open. So far the only examples trying to prove him wrong are pretty simple, despite their length. When I've tried to keyin things that have 4, 6, or more levels of parentheses open at once at different points, I do often make mistakes and have to go back and count and pair the parentheses to find my error. This may be one reason why, when I need a calculator, I normally reach for my RPN calc instead of an algebraic one.
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hi Valentin and Hi Chris,
I meant to make a post some time ago covering this very topic. Have not had the time to do it. Still plan on doing it someday.
So, let me start by saying that my working hypothesis is not that one or another logic is "better" but rather that "it depends on what you are doing."
BTW I used My HP 11c to do the test above, got an answer I did not trust. Then, I did it on the 20s (algebraic typebut not formula entry like Valentin's) and I got 881.6232 the first time (this is one order of magnitude smaller than Valentindid not do it again). Then I did it again on the 11c, and I lost the intermediate value of about 192 (from the left side) while working through the right side.
Clearly, if you just go in and "mash potatoes" that are already written in front of you, the Algebraic, or the Formula Entry, will work better. I have been RPNonly from 1982 until last year, and I still did better with the "Algebraic").
But this is really not why we like RPN. We like RPN for "Running calculations" or, where no formula is written downgenerally we like RPN because it works very well with the process of actually solving and developing an "equation" as opposed to "mashing potatoes" which are already in front of you.
This is also an outstanding distinction between classic Algebraicswhich are actually postfix for everything except the arithmatic opperatorsand the "Formula Entry" wich are infix for everything except x^2 x^3 etc. For the earlier "algebraics", if you are figuring out something, and you have done some arithmetic, and you have a value sitting in the display, and you look at your sketch and say, "ohI need to take the sine" then it is a simple matter to hit <SIN> and then keep moving.
Conversely, on a "Formula Entry" )also known as VPAM SVPAM or DAL etc), you have to type <sin(> and then find the "ANS" button, hit <ans>, then hit <enter> and then, finally, you have it! Some earlier models with this "formula" paradigm do not even have an "answer" button! And it is usually a shifted function, too!
So, really, it depends on how you use your device.
I personally find the RPN better most of the timebut not always. Period.
In fact, I like algebraic better for doing accountingas it mimics the keyflow of the "adding machine logic" (except that you are infixexcept it feels the same, as the last "+" which is open, has effectively finished the last addition, tooif you don't know what I'm talking about, don't worry).
regards,
Bill
Posts: 126
Threads: 19
Joined: Jan 2012
Quote:
Please explain why my example is deemed not adequate by you.
The method you described is the only method I ever remember seeing or using, to add a long list of numbers, so yes that is how I would do it by hand too. The method is virtually identical if that list contains only two numbers, if you can't see how it is related to the concept of post fix notation I don't know how I can explain it.
Quote:
The one and only way, in my vast experience, is for me and you to meet in person, and let you see with your very own eyes what I'm talking about, when confronted with a variety of examples theoretic or from real life. Nothing else would make a dent in your convictions, only hard facts face to face. Any number of examples I could give in writing are going to be useless, only a personal demonstration would do.
I don't believe that a face to face meeting is necessary to show me anything other than you are probably much faster at reading an equation and hitting the corresponding buttons on your calculator than I am. If you believe it would show something more substantive, I will happily buy you dinner, and we can discuses it if you are ever in the Oklahoma City area, or if I am ever in your neck of the woods (where ever that is).
Quote:
Ok, try this one, written exactly as it appears on an engineering book:
((8.8+3.2)*(8.6+7.9)+(5.1+4.1)*(4.7+2.1))*((6.2+4.4)*(1.39.5)+(6.33.2)*(2.45.7))
So you found an example that requires a 5 level stack to calculate with RPN, I'm sure you could find or make up one that requires 6 or 7 levels too. My request was for a "real world" example. This may or may not be a real world example but the fact that it "appears on an engineering book" doesn't mean it is a real world problem.
Quote:
[. . .]will instantly return the *final* result (not the intermediate garbage).
This statement shows a clear bias against RPN. The intermediate values may not always be needed, but they are often very useful. There is no law that says, "when using RPN, you must examine the intermediate values after every operation."
Quote: Did you get it correctly first time ? (8816.232)
Yes on an HP 48GX.
Quote: Did you have to quickly scan the expression to see where to begin ?
No.
Quote: Did you have to think if 4 levels would suffice[. . .]?
No, I was pretty sure 4 wasn't enough, that is why I used my 48GX
Quote:
Assuming you now need to change that 7.9 in midexpression to 9.7, did you have to repeat the entire calculation from scratch ? I didn't, I just recalled the whole expression to the display with a single key, then placed the cursor over 7.9 and keyed in 9.7, then [ENTER]. The new result appeared instantaneously, no extra retyping needed, at all. What about you ?
If this is how you use a calculator, algebraic entry may well be the thing for you. However, that is not how I use a calculator. Other responses to your previous post explain that as well or better than I could, so I won't expound on it here.
Chris W
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Chris:
Chris posted:
"The method you described is the only method I ever remember seeing or using, to add a long list of numbers, so yes that is how I would do it by hand too. The method is virtually identical if that list contains only two numbers"
Yes, but that's not my example, which clearly states "a list of 10 or 12 elements", not two. You can't change my example to what you'd like it to be, and then argue that it doesn't hold.
For lists of more than two numbers, the fact is that people don't follow the "natural" RPN way, but rather another quite different method, and they don't see any intermediate results, which they don't want or need anyway. That's my example, it's universal, and I rest my case that it's a perfect counterexample and an incredibly frequent one at that, happening all the time.
"If you believe it would show something more substantive, I will happily buy you dinner"
Thanks but come to think of it, I agree with you on this one, it would be useless. As the old saying reads: "There are none so blind as they who refuse to see."
"My request was for a "real world" example. This may or may not be a real world example but the fact that it "appears on an engineering book" doesn't mean it is a real world problem."
Uh !? Making your own definitions once again ? It does appear in an engineering book yet it isn't "a real world problem" for you ?? Great. As long as you make your own definitions on the fly and stick to them, it'll be quite difficult to win an argument against you. Wish I could do the same, instead of trying to be rational and objective ...
It seems to me that you somehow believe as a matter of faith that nothing in this world would ever require more than 4 levels. And if someone presented you with such an evidence, you would claim it doesn't apply. Great attitude, I like it.
Quite useful.
"This statement shows a clear bias against RPN."
Bias against RPN !? Me ?? You obviously don't know me, at all, nor did you ever read my articles, postings, letters, books, hear my lectures, see me attending customers trade fair after trade fair at the HP booth, etc, etc. It's like Palmer said, cults tend to demonize anyone dissenting of their beliefs. Else, why would you try an "adhominem" attack, labeling me as "biasedagainstRPN" ? Are you so devoid of real arguments to try such a low trick ? What's next ? That I'm not a USA citizen ?
" The intermediate values may not always be needed, but they are often very useful."
Or not. In my example, why on Earth would you want to know or even see how much is it the chicken plus the fish, the chicken plus the fish plus the dessert, the chicken plus the fish plus the dessert plus the wine, etc, etc ? Wouldn't your mind accept that many times intermediate results are a nuisance, useless numbers noone wants to even look at ?
"Quote: Did you get it correctly first time ? (8816.232) Yes on an HP 48GX [...] I was pretty sure 4 wasn't enough, that is why I used my 48GX."
Ah, I see !! A new change of rules !! I thought we were discussing classic 4level RPN vs. true algebraic and now you introduce nlevel RPL (not RPN) into the discussion, so that my arguments, examples and questions cease to apply !
And it catches me with the guard low, not having prepared anything against multilevel RPL ! Wow !
Clever, Chris, very clever. Except for the fact that you chickened out and had to resort to just plain *cheating* , using one of the topoftheline, most advanced RPL (*not* RPN) models to essentially avoid trying my example and answering my questions in a classic RPN machine, as intended, because you feared that 4level wasn't enough (you just were "pretty sure", not downright positive; that would require carefully prescanning the expression, isn't it ?), while I can compute said expression without even batting an eyelid even in the *lowest*, bottomoftheline SHARP machine I own. Doesn't that ring a bell ?
But I'm done with you. The moment you learn how to conduct a proper, rational discussion, without "adhominem" attacks, without redefining terms on the fly, without trying to be both judge and defendant, without changing the rules at your convenience, and, if at all possible, with a positive attitude to see if your learn something worthwhile, I'll be amenable to resume this argument.
But as it is, I'm tired of this, and regrettably, as I feared, I'm losing my time with you.
Long live RPN !
Take care, and best regards from V.
Edited: 30 June 2004, 9:11 a.m.
▼
Posts: 126
Threads: 19
Joined: Jan 2012
Chris W
Quote: You can't change my example
I didn't change your example, I was using an other example to show the connection. While it may not be exactly like RPN it is very similar. A connection that you apparently can't or won't see.
Quote: Thanks but come to think of it, I agree with you on this one, it would be useless.
The invitation is still open.
Quote: Making your own definitions once again ?
I am doing nothing of the sort. "Real World Example", is obviously open to interpretation and as such deserves a lot more discussion than simply stating it came from an "engineering book".
Quote: Bias against RPN !? Me ?? You obviously don't know me
No I don't, but that doesn't change the fact that the statement shows a bias against RPN. You may or may not have a bias against RPN, and showing that at some time in the past you were not biased against RPN, does not have any bearing on today. One thing is clear you either have a bias against RPN, or a bias against people who have a bias for RPN, or both. Yes I have a bias for RPN, I have never tried to hide that, but that doesn't mean I have a closed mind.
Quote: In my example, why on Earth would you want to know or even see how much is it the chicken plus the fish
I may or may not want to know that, depends on who ate the chicken and who ate the fish. But you are taking yourself out of context. Your "intermediate garbage" comment was made after your example you claim is a real world example. Since you refuse to put any more effort into defending your claim of it being a real world example than simply stating it is from an engineering book, I have no way of knowing if the intermediate values would be of use to me. As I said before, it may or may not be a real world example, I need more information before I can form an opinion on that.
I have never said that RPN is perfect. I have also never said that real world problems that require more than a 4 level stack do not exist, I just don't know of any. If there are problems like that cormel found in your world the obviously a traditional 4 level RPN calculator isn't for you. Which gives me an idea for an RPN calculator with a dynamically sized stack that unlike the 48 series still has a top that gets copied on stack drop operations. Maybe something that started with 4 levels and could expand up to say 10 levels. I bet someone could write a program for a 41 or 42 that would work like that. But I digress.
It is hard to be sure from just reading words on a page, so I could very well be wrong, but you seem to have a hostile tone to your post. As for myself, I am quite enjoying this exchange. I hope it continues and hope others will interject their thoughts and examples. I am especially looking forward to Bill Platt's promised future discussion on this topic.
Chris W
Posts: 15
Threads: 5
Joined: Jan 1970
Hi Chris, Valentin, Karl, Bill, et al.,
I'd like to add my own .02 cents worth to this discussion :) First off, I'd like to say that I think that some of the comparisons being made are, quite simply, apples vs. oranges. Why? Well, let's analyze what exactly is going on here.
In one message, Valentin said that "even the lowest bottomoftheline Sharp calculator" that he owns allows him to enter a program from an engineering textbook exactly as it was written and come up with the correct answer. That might be true for his simplest AOS calculator but not for everyone's. For example, on the TriumphAdler Concorde 2 the maximum number of levels of parentheses allowed is 3. On the Sinclair Enterprise Programmable only 2 levels of parentheses are allowed, and on the Sinclair Cambridge Programmable there's only 1, yep, count 'em, 1 level of parentheses allowed. So it's quite unfair to be comparing calculators that have an infinite number of parenthetical levels against an RPN calculator with a 4 level stack. That's apples and oranges. If you want to compare infinite parentheses, then the only fair comparison is against an RPN calculator with an "infinite" stack (actually only limited by memory).
Second, the claim that an AOS calculator with a command line buffer to enter expressions can "run rings around any RPN calculator" is simply unfair. These types of calculators are tiny computers, really, and of course anyone can edit the contents of the command line buffer without having to retype the whole expression. That goes without saying, but one shouldn't compare these units against a calculator that has a fixed number of stack levels. Instead, one should compare them against RPL based calculators, which also allow the user to edit anything without retyping the whole expression over again.
And third, wouldn't it be nice if all the equations we use were handed to us on a silver platter and already printed out in some engineering textbook for us to use? Yeah, that sure would be nice, but in the real world, someone has to write down the parentheses, someone has to figure out where the opening parentheses go, someone has to figure out where the closing parentheses go, and someone has to check whether there are the right number of opening and closing parentheses, and by the time that "someone" has gotten all that headache out of the way, the person with the RPN calculator will have already figured out the right answer!
I think Bill Platt hit the nail right on the head when he said: "But this is really not why we like RPN. We like RPN for "Running calculations" or, where no formula is written downgenerally we like RPN because it works very well with the process of actually solving and developing an "equation" as opposed to "mashing potatoes" which are already in front of you."
Real world answers. For real world people.
Oh well, that's just my two .02 cents, for what it's worth... :)
▼
Posts: 1,841
Threads: 54
Joined: Jul 2005
Posts: 785
Threads: 13
Joined: Jan 2005
I just saved this answer to HD (as a web page)
I could have NOT possibly said it any better myself
(V+P*N)
Posts: 1,041
Threads: 15
Joined: Jan 2005
First, I'll say that I cheated a bit and simply edited the
expression to be enclosed in '' delimiters, copied it to the 49g+,
and evaluated it there.
It seems to me that it's a good example of what RPL models are
good for. If you already have the expession in algebraic form,
simply copy it straight into the command line and evaluate it.
Compare, this in the command line:
'((8.8+3.2)*(8.6+7.9)+(5.1+4.1)*(4.7+2.1))*((6.2+4.4)*(1.39.5)+(6.33.2)*(2.45.7))'
followed by EVAL, and this in the command line:
8.8 3.2 + 8.6 7.9 + * 5.1 4.1 + 4.7 2.1 + * + 6.2 4.4 + 1.3 9.5  * 6.3 3.2  2.4 5.7  * + *
followed by ENTER, or more commonly:
8.8 3.2[+]8.6 7.9[+][*]5.1[+/] 4.1[+]4.7 2.1[+][*][+]6.2[+/] 4.4[+]1.3 9.5[][*]6.3[+/] 3.2[]2.4 5.7[][*][+][*]
An RPL model allows all of these methods and variations of them
such as pressing ENTER instead of SPC, and the result is 8816.232
as long as you do it right.
Regards,
James
Posts: 1,792
Threads: 62
Joined: Jan 2005
Valentin provided the following example:
Quote:
Ok, try this one, written exactly as it appears on an engineering book:
((8.8+3.2)*(8.6+7.9)+(5.1+4.1)*(4.7+2.1))*((6.2+4.4)*(1.39.5)+(6.33.2)*(2.45.7))
Any of my SHARP calculators, even the simplest, will acept me to key it in exactly as written:
((8.8+3.2)*(8.6+7.9)+(5.1+4.1)*(4.7+2.1))*((6.2+4.4)*(1.39.5)+(6.33.2)*(2.45.7)) [ENTER]
and will instantly return the *final* result (not the intermediate garbage).
I'm sure that most users recognized several things about the expression:
 the example problem was symmetrical  a product of two long, identicallyconstructed terms, each consisting of a sum of two products of twoelement sums  alles klar?
 The expression utilized rules of mathematical precedence to allow omission of several more sets of parentheses.
 The 32SII "classic 4element RPN" worked well if one had the sense and foresight to store the first major sum in a register. A 4element stack is necessary and sufficient to calculate each major sum.
 The HP20S algebraic worked correctly, but entering all those "( )" slows the user down. No thinking required, though!
 The HP10B and HP17BII (in algebraic) give incorrect answers unless the user inserts extra parentheses at the required places.
 The HP48G worked well with its unlimited stack. If the expression was to be revised or revisited, its editable algebraic expressions fit the bill.
 The $15 Casio fx115MS "SV.P.A.M" failed  its buffer was not quite large enough to accept the entire expression. Nice crisp display, though. ;)
BTW, I don't believe that intermediate results are "garbage"  they allow checks for "reasonableness" of each step. That's what addingmachine calculators do, to use Valentin's restaurant example.
 Karl S.
Edited: 1 July 2004, 1:40 a.m.
▼
Posts: 4
Threads: 0
Joined: Jan 1970
Karl Schneider gave a good summary, with one mistake:

* The $15 Casio fx115MS "SV.P.A.M" failed  its buffer was not quite large enough to accept the entire expression. Nice crisp display, though. ;)

Actually it gives the correct answer. If you eliminate entering multiplication signs between parentheses, the expression fits, with the exception of the final closing brackets. However, the calculator logic will add them automatically if they are not entered by the user. Eg Entering the expression
(5+7)(52 =
gives 36.
I have to say, I am very impressed with the Casio. Sure, it's not programmable, but it does incude a solver, plus programs for quadratic and cubic solving, systems of 2 and 3 variables, linear and quadratic regression, and some stats. Complex number handling is pretty bad, but I never need them anyway.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
W Rice stated,
Quote:
Actually it gives the correct answer. If you eliminate entering multiplication signs between parentheses, the expression fits, with the exception of the final closing brackets.
And you are correct! I forgot about that feature of "multiplication by juxtaposition". I still maintain, however, that the expression didn't fit in the buffer. It was fortunate that the last two characters in the expression  after omitting unnecessary "*"  were "))".
Quote:
I have to say, I am very impressed with the Casio.
I bought the fx115MS because I saw that it had complexnumber handling, and I wanted to see how well it was implmented in a unit costing only $15. Also, I have a 1981 fx3600P (which served me well until I bought my HP15C two years later), and wanted to see how Casio calc's had evolved over the past 23 years.
I'm very impressed by its amount of functionality and its crisp 2line dotmatrix/7segment LCD readout, but not at all impressed by its poor productdesign engineering. Whereas the fx3600P was a nononsense tool like the HP's, this fx115MS is more like a student's training aid. There's lotsa stuff in it  including things that none of my HP's have  but it's just not a very coherent package. To wit:
Unintuitive and cumbersome usage  For example, on the fx3600P, shifting to radianmeasurement mode is simply "[MODE] 5" (which is printed on the face), and you get a nice "RAD" annunciator. On the fx115MS, it's "[MODE][MODE][MODE][MODE] 2" (not printed on the face), and you get an "R" inside a tiny square as an annunciator. Is this progress?
The user interface of the linearequation solver (limited to 2 or 3 unknowns) is utterly befuddling to one who hasn't read, understood, and remembered the instructions in the foldout manual.
Lack of Consistency  On the fx115MS, many unary mathematical functions are prefix; others are postfix  depending on how the function is is denoted by the calc.
Lack of Funcitonal Interactivity  On the fx115MS,the user enters a "mode" for performing one kind of function  say, linear systems. When the user wants to do something else  say, complex numbers or a display change, s/he enters a different "mode", and all the work performed in the previous mode is lost. The user can essentially do one thing at a time. The HP15C was absolutely nothing like that  all its functions were complementary and always available.
Thus, we see the difference between "tools for professionals" and "aids/toys for young students".
Edited: 2 July 2004, 11:51 p.m. after one or more responses were posted
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hi Karl, et al:
You can apply pretty much everything you said about the Casio fx115Ms to the HP 30s. It too has an 80 character buffer, which just barely allowed Valentin's "equation" in.
It too, has the mode thing, the "press the buttons just like you would on paper!" blah bla blah (which means x^2 is postfix, and Square root is prefix......)
More on this topic later.
BTW I bought the 30s for $4.95.
One of my coworkers uses the Casio you mentioned. It is the first time I saw one of these "formula entry" or "VPAM" type machines. Her father used an HP45and she gave it to me, knowing how much of an HP collector I have becomea very generous gift, yes! Question is, how on earth to properly reciprocate?
Regards
Bill
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Bill:
Bill posted:
"she gave it to me, knowing how much of an HP collector I have becomea very generous gift, yes!
Question is, how on earth to properly reciprocate?"
Did you try the [1/x] key ?
Now seriously, all else failing, buy her a dinner. That always works ! :)
Best regards from V.
Posts: 120
Threads: 11
Joined: Jan 1970
First, on my 28S, 48SX, or 48GX I can enter a problem in algebraic format when ever I am so inclined.
Second, if algebraic entry is so wonderful why are half the functions on an algebraic calculater used in RPN mode? For example sin(.5) is entered as .5 sin. If that ain't RPN what is it? And what's it doing on my TI, Casio, El Cheapo, etc.?
I find that in most calculations RPN saves keystrokes and does play out faster than algebraic. And my first calculator was an El Cheapo algebraic followed by a graphing algebraic, followed by a high powered scientific algebraic (Lost the grapher), before I ever had an HP.
Posts: 1,841
Threads: 54
Joined: Jul 2005
Hello,
>They were hard facts for a time, circa 1980 or so.
>
Right. Back then HP RPN calculators
were the only calcs with reliable keyboards.
Back in 1980, when I had to decide which
calculator to buy, I tested many new TI's,
Casios, Sharps, and other brands,
and all had unreliable keyboards,
except the HP calcs.
>They're myths ever since,
>
>and nowadays RPN is plain and simply obsolete
>
This is just your opinion, and not a fact.
Obsolete is something that nobody wants or needs.
There may be not as much people needing or wanting RPN calcs than algebraic calcs,
but there are some, so there's need.
There are even new calculator models with RPN,
switchable to kinda lowlevel algebraic mode.
It's my observation that even in the last few years,
I could do simple (and more complex) calculations faster with my HP41 or HP48 than my colleagues with their Casios, or even with their fourbangers.
This is (amongst other things) due to the fact that
number corrections in case of entry errors are easy
compared to many of the algebraic machines.
Fourbangers force you to restart the calculation from scratch,
the more advanced machines with a command line force you to scroll through the line up to the wrong digit(s).
In addition, I make less entry mistakes with an HP41 or HP48 because I can be sure the calc registers each entry I make.
Ok, the newer Kinpo machines are not as trustworthy,
but the current calcs of any brand aren't better is this respect.
BTW, you didn't proove that RPNlike entry is less 'natural' than algebraic entry.
So if you add numbers in a different way when using pen and paper instead of a calculator, RPN or not, this is NOT an argument for or against RPN in itself.
At least your addition example is a good example to show that the RPN entry method is much nearer to the 'natural' way of calculation than algebraic entry.
The intermediate results are a (positive) side effect,
you can use them or not.
As always, people should choose the right tools for their work.
So if you find it easier to do simple additions with an algebraic calc, that's no problem.
It's also a matter of personal taste.
The increased command line options of modern algebraic calcs aren't really an argument, because you could do this type of entry for many years with an HP28C.
And that's an important point: You have the choice of either entering your numbers RPNlike or in an algebraic manner, at least with many Saturnbased HP calcs, like the HP17BII, HP28, and HP48 series.
Ooops, I nearly forgot the hp33s, which is not a Saturnbased machine, strictly speaking.
Regards,
Raymond
Posts: 126
Threads: 19
Joined: Jan 2012
Quote:
So, I suggest that the best answer to the request is simply "It's a cult thing."
Quite frankly, that is ridiculous. I don't dispute that there are those among us that have a cult like following to HP calculators. However, the fact that many consider the 48 series to be the last quality calculators built by HP, shows that the following is much more complex than that.
My evaluation of just about everything I buy is largely based on the answer to one simple question; "does it make my life easier?" When comparing product A and B, the obvious corollary is, "which one makes my life easier?" When it comes to calculators the 15C or 11C are the clear winners over anything else I have seen. It's not just RPN either. RPN is a huge factor though, and enough to make it a deal breaker. But if RPN was the only thing about the 15C that made it make my life easier, I certainly would have put up my Bring Back the HP 15C web site. After RPN the biggest way the 15C makes my life easier is by making it so I don't have to look at the display after ever button press to be sure it took. Finally, it makes my life easier because it fits in my shirt pocket so it will be handy when I need to calculate something. See my other post in this thread for more on why RPN is a deal breaker when it comes to calculators. There are many other factors too, such as battery life and over all quality.
I think the best answer to the question from the TI employ was suggested by someone over on comp.sys.hp48, just read the web site it is all pretty much there.
Chris W
Posts: 673
Threads: 20
Joined: Oct 2008
Ti no longer releases a pocket programmable either. They should.
If Ti were to rerelease a Ti66 with RPN and a softclick, you would also be happy. Actually, a Ti67 with better keys and an RPN option would make us all happy. Of course if they incorporated more of your ideas, even better.
Posts: 901
Threads: 113
Joined: Jun 2007
Before presenting some detailed matrix results I want to add something to those comments that suggested that the HP71 should have provided an RPN calculator capability. Sometime in the early 1980's (thereabouts, my memory isn't what it used to be, my read amplifier must be failing) an HP sales representative visited the company where I worked. He started with a pitch for the HP41, and of course included a discussion of the superiority of RPN. Then, he made a pitch for the HP75 (I thiink, but it may have been the 71) and described its calculator mode. I raised my hand, reminded him of his discussion of the advantages of RPN, and asked why the 75 didn't offer an RPN mode. He thought for more than a few seconds before replying that if you wanted RPN you used the HP41, otherwise you could use the 75.
Why did I use a TI59? My company participated in the productivity improvement program marketed by TI. I took an eight session evening course and when I passed the test I was given my very own TI59, free and clear. I found that it was very easy to transfer some of my workhorse mainframe programs written in BASIC or FORTRAN to my TI59. When the HP41 arrived on the scene I looked very hard at it. For one thing it had a vastly superior alphanumeric capability. But when I tested some matrix problems that were important in my work I found that it just didn't do as well as my TI59.
You may wonder where all the following matrix material is coming from. One of my current projects is working with Richard Nelson, the former editor of the PPC Calculator Journal, on a history of the old socalled "friendly competition" between users of HP and TI machines. Matrix manipulation is one of the subjects. Another was the calculation of 1000 digits of pi competition. You may have noted that some time ago Gene Wright published my work with the TI95 in which a TI machine finally yielded faster results than those achieved with the H41. Gene could not rest until he had coached someone into converting the old HP41 program for use on an HP42 and once more claiming the pi finding competition for the HP product line. That dedication reminded me of superprogrammer Roger Hill's comment during the calendar printing competition when he noted that the "friendly competition" looked a lot like "allout war".
The following table compares the column by column results reported for the HP15 with those obtained with the HP41 Math Pac and with the ML02 program in the Master Library of the TI59. The relative error for an element of the solution matrix is defined as (calculated  exact)/exact.
Test Inverse HP15 HP41 TI59
Matrix Matrix
6  5 5.000000049  4.99999997  5.000000000099
 2  11 11.00000011  10.99999994 11.00000000026
2  7 7.000000067  6.999999965  7.000000000168
 3  1 1.000000011  0.999999995  1.000000000030
 1  6 6.000000059  5.999999967  6.000000000122
0  13 13.00000013  12.99999993  13.00000000031
 1  8 8.000000080  7.999999955  8.000000000201
2  1 1.000000013  0.999999994  1.000000000035
 3 23 23.00000022 22.99999988 23.00000000044
1 50 50.00000048 49.99999973 50.00000000115
0 31 31.00000030 30.99999983 31.00000000075
 1 5 5.000000048 4.999999975 5.000000000130
1 9 9.000000085 8.999999949 9.000000000155
3 20 20.00000019 19.99999989 20.00000000042
1 12 12.00000012 11.99999993 12.00000000027
0 2 2.000000019 1.999999990 2.000000000050
RMS Relative Error 1.004E08 5.40E09 2.41E11
The RMS relative error for the elements of the inverted matrix for the HP15 as reported in the Kahan paper is 416 times larger than that from the ML02 prgram of the TI59 Master Library. The RMS relative error for the HP15 is a factor of two worse than the results obtained with the HP41 Math Pac.
The TI59 results which are displayed or printed from ML02 would suggest that it had arrived at an exact solution. But every serious user of the TI59 knows that the displayed value is a rounded value derived from the 13 digit display register. The value for the TI59 in the table above were extracted from the display register.
The text of the Kahan paper indicates that the results for the HP15 were obtained by entering the test matrix and performing the inverse by using 1/x. The paper mentions iterative refinement as described on pages 119121 of the HP15C Advanced Functions Handbook but doesn't present any results. I don't have an HP15C so I can't provide the results with iterative refinement. I do have an HP28S. One cycle of iterative refinement as defined on pages 6869 of the HP28S Reference Manual provides an exact result.
The Kahan paper also mentions the inversion of a much more difficult matrix, an 8x8 Hilbert multiplied by 360360 so that the test matrix is made up of all integers. The paper reports that the HP15C inversion recovers three correct significant figures. The RMS relative errors for that problem for several machines are
4.134E04 HP41 using the Advantage MATRX routiine
1.818E05 TI59 using ML02
7.249E06 TI85
1.309E06 HP28S using iterative refinement from page 69 of Reference Manual
▼
Posts: 163
Threads: 7
Joined: Jul 2007
Strange that an RPN program for the 41C would produce better results than a microcode program for the 15C,
that allegedly uses the full 13 internal digits for dot products? The TI59, of course, benefits from its 13 digits at every step.
Werner
Posts: 412
Threads: 40
Joined: Mar 2006
I'm not surprised that TI59 gives more accurate answer that HP41, the 13 digits of the 59 vs the 10 of the 41C were well known at that time.
I just tested the HP71B (the first Saturn machine, with internal 15 digits), actually I used Emu71 here at my office because I don't have my real machine here. Of course I got better results, but not as good as the TI59, which indeed surprised me:
10 !  TSTMAT 
20 DIM A(3,3),B(3,3)
30 ! Test matrix
40 DATA 6,2,2,3
50 DATA 1,0,1,2
60 DATA 3,1,0,1
70 DATA 1,3,1,0
80 ! Inverse matrix
90 DATA 5,11,7,1
100 DATA 6,13,8,1
110 DATA 23,50,31,5
120 DATA 9,20,12,2
130 READ A(,),B(,)
140 MAT A=INV(A)
150 MAT A=AB
160 DISP FNORM(A)
result is 1.1E10.
BTW, see how easy are matrix calculations on a good ALG machine :)
JF
▼
Posts: 412
Threads: 40
Joined: Mar 2006
Sorry, I think I made a mistake, FNORM function returns the square root of the sum of square values. To get the RMS error, FNORM should be divided by sqrt(n), so the result is 2.8E11, close to TI59 accuracy.
JF
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Jean François, Palmer and all interested in this thread:
Jean François posted:
"I just tested the HP71B (the first Saturn machine, with internal 15 digits) [...] Of course I got better results, but not as good as the TI59, which indeed surprised me [...] To get the RMS error, FNORM should be divided by sqrt(n), so the result is 2.8E11, close to TI59 accuracy."
As I said earlier in this thread, there are more ways to skin a cat than you may think at first. The HP71B/Math ROM can run rings around the TI59 in terms of accuracy, if you just make proper use of the available tools.
For this particular example (and everytime you want or need increased accuracy for matrix inversion), you should do it like this (which by the way, it's not a happy idea of mine, but rather it's perfectly documented in the Manual):
100 !  TEST MATRIX INVERSION  Valentin Albillo's version
110 !
120 ! declare and dimension matrices
130 !
140 DESTROY ALL @ OPTION BASE 1 @ DIM A(4,4),B(4,4),C(4,4)
150 !
160 ! data for original test matrix
170 !
180 DATA 6,2,2,3,1,0,1,2,3,1,0,1,1,3,1,0
190 !
200 ! data for exact inverse matrix, for testing inverse's accuracy
210 !
220 DATA 5,11,7,1,6,13,8,1,23,50,31,5,9,20,12,2
230 !
240 ! fill up both matrices with the corresponding elements
250 !
260 READ A,B
270 !
280 ! compute in place and display the inverse matrix
290 !
300 MAT C=IDN @ MAT A=SYS(A,C) @ DISP "Inverse matrix:" @ MAT DISP A
310 !
320 ! compute and display the norm of the error matrix
330 !
340 MAT C=AB @ DISP "Norm of Error = ";FNORM(C)
Upon running this program, the output is:
>run
Inverse matrix:
5 11 7 1
6 13 8 1
23 50 31 5
9 20 12 2
Norm of Error = 0
and, as you may see, the norm of the error is zero, i.e., the error matrix is a zero matrix, i.e., the inverse is exact.
How's that for accuracy ? Does it beat the TI59 ? The moral: Never, ever, subestimate past HP's ingenuity :)
Best regards from V.
Edited: 29 June 2004, 12:35 p.m.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
I don't have a TI71 so I can't respond directly. The HP28S with one iteration of refinement also gets the exact answer to the 4x4 problem.
The HP28S does not get exact answers, even with iterative refinement, to more difficult problems such as
(a) the modified 8x8 Hilbert as defined in Kahan's paper, which is a standard 8x8 Hilbert multiplied by 360360 so that all elements of the test matrix are integers. It does get about 4 digits correct with only an inversion, and about six digits correct with one iteration of refinement.
(b) a set of linear equations defined by a 7x7 subHilbert, (A(i,j) = 1/(i + j), as the matrix and seven ones as the vector. In this case it exhibits an interesting characteristic in that an iteration of refinement degrades the solution. The solution vector is 56, 1512, 12600, 46200, 83160, 72072, 24024 .
Several individuals have told me that both the HP49 and TI89 are able to solve both of these problems exactly. I would be interested to know what the HP71 can do.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi again, Palmer:
Palmer posted:
"I don't have a TI71"
Neither do I. Really, Palmer, you should test the correctness of the things you post/publish, you seem to have a definite problem with that ! :)
"The HP28S does not get exact answers, even with iterative refinement, to more difficult problems"
Iterative refinement depends upon the convergence radius of the Taylor series expansion it is based upon, which is valid for arguments < 1 in absolute value. If the norm of the first approximation to the inverse matrix is too large (i.e., the error is too big and the approximation is not that 'approximate'), it won't converge at all, and you'll get worse and worse 'refined' inverses.
"Several individuals have told me that both the HP49 and TI89 are able to solve both of these problems exactly. I would be interested to know what the HP71 can do."
The one and only reason why these calculators are able to come up with exact solution is that their users specified Exact mode where exact arithmetic is used all the time, never performing an actual division unless the numerator happens to be exactly divisible by the denominator. As such, there are neither approximations nor rounded results at all, and the final result is exact.
The HP71B has no symbolic math capabilities nor an Exact mode, so it will perform operations with 15digit mantissas and in such anomalous, illconditioned problems you can't realistically expect it to get an exact solution. Just try these problem in the calculators you mention without using Exact mode and see what you get instead.
Best regards from V.
▼
Posts: 113
Threads: 20
Joined: Sep 2013
I computed the matrix inversion on the 49g+ in approximate mode with the simple 1/X, and the result is exact. But I also tried 1/X on the result, and that result is inexact, diplaying roundoff error.
How does the HP 71b fare on the inversion of the inverted matrix? Just curious.
Posts: 412
Threads: 40
Joined: Mar 2006
Thanks Valentin, now I remember that SYS gives more accurate answer than the INV command. Also for early HP48SX (at least the rev.A), HP recommended to use SYS command for matrix size > 8 (or so, don't remember the exact limit) instead of INV due to a bug.
Question: if SYS command gives always better results than INV, why INV doesn't use the SYS algorithm? Maybe are there some reasons regarding memory usage, speed, ...
JF
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Jean François:
Jean François posted:
"HP recommended to use SYS command for matrix size > 8 (or so, don't remember the exact limit) instead of INV due to a bug."
A bug ? In the Math ROM ? Details, references, anything ?
"Question: if SYS command gives always better results than INV, why INV doesn't use the SYS algorithm? Maybe are there some reasons
regarding memory usage, speed, ..."
All of the reasons you mention. Computing an inverse using SYS is equivalent to solving N systems of N equations in N unknowns, all at once, and this uses extra blocks of memory and takes significantly longer. But if you can afford the extra RAM and time needed, you'll be rewarded with increased accuracy. It's all in the manual.
BTW, I didn't forget your request, I'm trying to locate that d**ned bug list ! I've misplaced it yet again !! :)
Best regards from V.
▼
Posts: 412
Threads: 40
Joined: Mar 2006
>> "HP recommended to use SYS command for matrix size > 8 (or so, don't remember the exact limit) instead of INV due to a bug."
> A bug ? In the Math ROM ? Details, references, anything ?
No, I meant in the HP48SX rev.A (at least). I don't think that the HP71B MathROM has the same problem.
The only problem I was told about the HP71 MathROM is that INV command doesn't report any error if the matrix is not invertible (det=0), but it's not really a bug (this behaviour has some benefits).
JF
Posts: 44
Threads: 0
Joined: Jan 1970
Yes, strange indeed.
Because the INV algorithm executes the same steps
as a SYS  albeit perhaps in a different order, and
without ecplicitly forming a unit matrix. But from
a numerical point of view, the error analysis is the
same  the algorithm is the same.
It is true that to solve a general system, solving (AX=B)
is (way) better than calculating X = INV(A)*B, but
if B is the unit matrix, it amounts to the same thing.
So I wonder why it is different in the 71B?
Cheers,
Werner
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi Palmer, Werner, and all interested in this topic:
Werner posted:
"Strange that an RPN program for the 41C would produce better results than a microcode program for the 15C, that allegedly uses the full 13 internal
digits for dot products?"
Strange indeed, but easy to explain and that's exactly why I asked for "hard data" and precise details before committing to an opinion. Actually, the explanation is simplicity itself: Palmer's quoted results for the HP15C are utterly wrong !.
Of course I've noticed that he explicitly states that he doesn't own an HP15C and took said results from some Kahan's paper. But anyway, I think he should have verified the correctness of those results, so much so as he is using them for comparison purposes and drawing conclusions or leading other people to make an opinion based on his quoted data.
The correct results for the HP15C (verified in all four physical HP15C's I own, i.e., 3 USAmade and 1 Brazilian unit) are easily obtained. After dimensioning a 4x4 matrix A and filling it up with the original matrix contents, I simply press [1/X] (as stated in Palmer's posting) and get the following:

Inverse elements My Palmer's My inverse after
after [1/X] ULPS ULPS one step refinement

4.999999986 14 49 5.000000000
10.99999997 3 11 11.00000000
6.999999981 19 67 7.000000000
0.999999997 3 11 1.000000000
5.999999982 18 59 6.000000000
12.99999996 4 13 13.00000000
7.999999975 25 80 8.000000000
0.999999996 4 13 1.000000000
22.99999993 7 22 23.00000000
49.99999985 15 48 50.00000000
30.99999991 9 30 31.00000000
4.999999985 15 48 5.000000000
8.999999973 27 85 9.000000000
19.99999994 6 19 20.00000000
11.99999996 4 12 12.00000000
1.999999994 6 19 2.000000000

Sum(ULPS) 179 586 0

As you may see, Palmer's quoted results for the HP15 are 300% worse(!!) than the actual results, when measured in ULPS
(units in the last place). As for the norms, we have
My results:
RNORM(CA) = 0.000000325
FNORM(CA) = 0.000000214
His quoted results:
RNORM(CA) = 0.000001048
FNORM(CA) = 0.000000689
also roughly 300% larger than the actual ones.
And last but not least, the HP15C does allow for refinement of the solution by using the builtin, microcoded RESIDUAL function. After applying just one step of refinement to the inverse computed using [1/X], we do get an improved inverse which happens to be the exact inverse (zero error), as shown above. For those wanting to know how the refinement step is done on the HP15C, the theory and practice are as follows:
Assuming B is a reasonably approximate inverse of matrix A, then you can get an improved inverse INV(A) by computing:
INV(A) = (I + R + R^2 + ...) * B
where
R = I  B * A
is the Residual matrix and I is an identity matrix of the same dimensions. Thus, to first compute the inverse and then perform one step of refinement, assuming A is a 4x4 matrix holding the original matrix, and C is a 4x4 identity matrix, proceed as follows:
RCL MATRIX C for convenience, we make a copy of C
STO MATRIX D D = C = 4x4 identity matrix
RCL MATRIX A recall A to compute its inverse
RESULT B specify that B will hold the inverse
1/X matrix B = inverse of A
RESULT C C will hold the residual R = IB*A
RCL MATRIX A
MATRIX 6 compute the residual R = IB*A in C
RCL MATRIX D recall the identity matrix
+ C now holds I+R
RCL MATRIX B recall the approximate inverse
RESULT A specify A to hold the refined inverse
* A = (I+R)*B, the refined inverse of A
and we find that the resulting refined inverse is exact, i.e., error = 0. The above procedure doesn't require any programming at all, and is carried out in seconds.
By the way, Palmer, I won't pretend to tell anyone what to do or how to behave but if I were you, I'd rather do my best to test the accuracy of any results I might publish and/or depend upon for the sake of an argument, making some point, or stablishing comparisons. Anything else means your conclusions are resting on shaky grounds, if at all.
Best regards from V.
▼
Posts: 131
Threads: 20
Joined: Mar 2011
Hi Valentin and all,
Just my 2 cents  you'll be happy to know that Lygea Pocket15C simulator gives instantaneously 100% accurate results for this problem without any residual computation, just simple '1/x'... That's the good thing about a simulator.
Elaborating about what was said about differences between simulators and emulators, I would say that:
 An emulator is appropriate when you can get the ROM image (not so obvious in the case of the 15C) and when you want to use the hacking possibilities of the machine, like synthetic programming on the 41C or Assembly on the 48. In the case of the 15C, no doubt that a few 'hacks' exist, but that's not the emphasis...
 A simulator is appropriate when you want to enhance the functionality of the machine, in terms of speed, accuracy, memory, and, in the case of the 15C, alphanumeric display of program steps.
 Therefore, I prefer a 41C emulator to a 41C simulator, but I also prefer a 15C simulator to a 15C emulator. Lygea's program does a wonderful job at this, and a good way to remain faithful to what HP used to be is to purchase an Ipaq 1930 or 1940. These are cool machines, light, small, reliable, with a good removable battery, and among the cheapest pocket PCs on the market. They can serve as an enhanced 15C, an enhanced 12C, and as a 41CX, on top, of course, of all the applications that PocketPC can run. Granted, the touch screen as not as good an option as keys are to type fast, and the battery life has nothing to do with a Voyager... but that's still a viable option (at least for me).
 I would actually love to have a 42S simulator: This is the typical case where hacking is not so important, but enhancing the functionality could be a big plus. The 42S is almost perfect, but lacks the equations and fraction mode from the 32SII, plus a decent solution for alpha entry, and a few more things on the display of complex numbers. A simulator could be a great thing... I started one, but stopped due to lack of time, unfrtunately.
Thanks and cheers,
Vincent
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Vincent, long time no read ! :)
Vincent posted:
"you'll be happy to know that Lygea Pocket15C simulator gives instantaneously 100% accurate results for this problem
without any residual computation, just simple '1/x'..."
Glad to see that you're still enthusiastic about the HP15C, even in its excellent simulated incarnation. I agree with most of the points in your enjoyable posting, but let me point out that I knew in advance that Lygea's simulator would have no problem at all with this smallish, 4x4 notillbehaved matrix, computing as it does to far greater precision than a real HP15C (or HP71B, 42S, etc., for that matter).
However, don't get blinded by that expected success. As soon as you step out of the small, wellconditioned matrices into larger, illconditioned ones, your Lygea simulator will fail miserably, as well, and much sooner than you think.
Just have a look at this link or this other link and try out an 8x8 Hilbert matrix, say. Compare your results with the exact inverse and see if a refinement step would be adequate or not. Larger matrices are exponentially much worse, just notice how incredibly small their determinants do get (2.737E33 for the 8x8 case), and remember that a zero determinant means the matrix is singular and has no inverse, so these matrices are extremely close to being singular and thus noninvertible.
Nice to 'hear' from you, and
Best regards from V.
Edited: 30 June 2004, 9:52 a.m.
▼
Posts: 131
Threads: 20
Joined: Mar 2011
Hi Valentin, nice to hear from you ! :)
Ho, I have no doubt that it should be possible to fail Lygea's simulator with illconditionned matrixes  I studied them, well, a long time ago, in 1991... And at that time even the HP48SX was doing a poor job... But how does the real 15C on theses matrixes ?
I'm not a religious fanatic of Lygea... :) But I still like Lygea's simulator a lot (and its 12C counterpart), because, having started myself a 42S emulator, I know what kind of work it is, and I think they really put all their heart into getting a reliable product... So, I spend a lot of time with my beloved Ipaq 1940 nowadays :)
Cheers,
Vincent
Posts: 122
Threads: 18
Joined: Jul 2005
I am very impressed by your mathematical knowledge (usually and here), but this time there is a catch in your ULP thingy.
The first two lines of your table show
A = 4.999999986 as 14 ULPS (???!!)
and B = 10.99999997 as 3 ULPS.
But A is closer to (5) than B is from (11).
I'm not certain what ULPS are good for, but that's probably not a measure of precision.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, GE(France):
GE(France) posted:
"The first two lines of your table show A = 4.999999986 as 14 ULPS (???!!) and B = 10.99999997 as 3 ULPS. But A is closer to (5) than B is from (11). I'm not certain what ULPS are good for, but that's probably not a measure of precision."
A is closer to 5 than B is to 11 only in absolute value of the error. An ULP (Unit in the Last Place) deals with relative errors, not absolute, so that we consider 10000000.01 as a closer approximation to 10000000.00 than 3.000000873 is to 3.000000000, because the former errs by only 1 ULP while the later errs by 873 ULPs, though the absolute errors are 0.01 versus 0.000000873, respectively.
"I'm not certain what ULPS are good for, but that's probably not a measure of precision."
On the contrary, ULPs are a widely accepted, used, and standard measure of precision, be they software (Mathematica) or hardware (Intel) guys. For a simple definition/explanation, see:
ULPs, Relative Error, and Machine Epsilon
Ulp
and, most interesting, revealing, and even amusing of all, have a look at:
Mathematica's Numerical Math Microscope
Thanks for your interest and kind words and
Best regards from V.
▼
Posts: 122
Threads: 18
Joined: Jul 2005
Now I get it. Thanks.
I like when I don't understand. It means I'm about to learn something.
Posts: 901
Threads: 113
Joined: Jun 2007
As I clearly stated in my presentation of the HP15C results they were not mine since they were taken from a paper written by another individual. That indvidual was not just anyone, but was Professor W. Kahan of the University of California at Berkeley. As I understand it he has been an important resource for HP calculator design, and in particular for the HP15C. His paper "Mathematics Written in Sand" appears in the 1983 Proceedings of the Statistical Computing Section of the American Statistical Association, August 1983. It is available on the net. I believe that anyone who is familiar with Professor Kahan's work would agree with me that I should be able to rely on his work. Also, when working on the general topic of matrix inversion accuracy earlier this year I received an email that stated "I tested the 4x4 matrix on my 15C, and got the same result as in Kahan's paper.
After looking more closely at Kahan's paper I think I may have found the source of the different results. I wrote that the results from the paper were obtained by entering the test matrix and doing an invert with 1/x. The paper actually states after completing the input:
"The next few keystrokes compute C ;= A^(1);
RESULT C ... Tells hp15c where to put A^(1)
RCL MATRIX ... See [A 4 4 ] displayed
[1/x] ... See [running for 11 sec.,
... then [C 4 4] .
The displayed descriptor tells the user that a 4x4 matrix C resulted from the last operation, and
is now ready for the next. To view the 16 elements of C, press [RCL] [C] sixteen times ..."
I trust that you will read A^(1) as the inverse of A as I do not have superscripts available for this writeup. Without an HP15C at my disposal I cannot, of course, verify that the results will be as in the paper. However, I trust that you will be able to do so. If you cannot verify the results in the paper let me know. I expect to have an HP15C avilable to me for a few days next month.
I do not know what all of this means. I am surprised that Professor Kahan would publish results for a matrix inversion method with the HP15C which would yield results less accurate than what are possible with the machine.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Palmer:
First of all, thanks for answering my concerns about the HP15C results you posted. Now for some comments:
Palmer posted:
"Also, when working on the general topic of matrix inversion accuracy earlier this year I received an email that stated "I tested the 4x4 matrix
on my 15C, and got the same result as in Kahan's paper."
That's strange. As I said, I own 4 physical HP15C units, 3 USA made and a Brazilian one, and all of them give my results, not Mr. Kahan's. Perhaps there were some ROM changes or perhaps Mr. Kahan was using some preproduction unit (he probably had one of the very first HP15C prototypes ever produced). I'll try to get other HP15C units to test the inversion, perhaps you could do the same, and perhaps some kind visitors of this forum could help posting which results they do actually get. I don't have the serial numbers of my USA made units available right now, but my Brazilian one is 2504B12xxx.
"After looking more closely at Kahan's paper I think I may have found the source of the different results".
Nope. If you read my post carefully, that's exactly what I did to get the inverse, prior to refinement:
RCL MATRIX A recall A to compute its inverse
RESULT B specify that B will hold the inverse
1/X matrix B = inverse of A
Apart from using matrix B instead of matrix C, this is the same sequence as the one you mention.
"I do not know what all of this means. I am surprised that Professor Kahan would publish results for a matrix inversion
method with the HP15C which would yield results less accurate than what are possible with the machine."
As I've said, perhaps it's a case of different 15C ROM batchs, or more likely, Mr. Kahan using a very early preproduction machine or prototype, or everything else failing, my four HP15C are gifted, who knows ? :)
A final advice, if you would: as I understand you're working in some project re the friendly HPTI competitions, it would be most proper to thoroughly test and validate each claimed program running times, results, and the like, made by both TI and HP sides, lest you'll find yourself embarrassed by nonreproducible, provably erroneous results. Unlikely perhaps, but a rigorous approach is mandatory for scholartype projects.
All of this posted in good spirit, of course, no offence intended :)
Best regards from V.
Edited: 1 July 2004, 7:46 a.m.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
Would you believe that both sets of HP15C 4x4 results are right?
I had trouble believing that there were HP15C's which gave different answers to the same problem although I knew that there were some minor differences between early and late model HP11C's. I still didn't have an HP15C to work with but then I remembered that Gene Wright had loaned a HP41 ADVANTAGE Advanced Solutions Pac to me, and that I had been told that the matrix routines mirrored the HP15C matrix routines very well. I ran the Kahan 4x4 problem with the Advanced Solutions Pac and got EXACTLY the same results as published in his paper for the HP15C and as published in my comparison of the HP15C, HP41 Math Pac and TI59 ML02 results. Then how could I explain Valentin's different results?
After some thought I ran the inverse of the transpose of the Kahan 4x4 problem with the Advanced Solutions Pac. I got EXACTLY the values that Valentin published saying that my numbers (really Kahan's) were wrong. I conclude that Valentin did not notice that before my table of comparisons I had stated that "The following table compares the column by column results ...". As Valentin said in one of his submissions the devil is surely in the details.
The substantially larger errors when doing the inverse of the Kahan problem as compared with the inverse of the transpose of the Kahan problen are mirrored with the HP41 Math Pac. For the inverse of the transpose the Math Pac gets nine of the sixteen elements exactly right, and the largest error in the remaining seven elements is only 4 in the tenth significant figure. The HP28S gets six of the elements of the inverse of the transpose exactly right. The HP28S does not get any of the elements of the inverse of the original problem exactly right, but does get an exact solution with one cycle of iterative refinement as defined on page 69 of the Reference Manual.
In the next few days I will do the inverse of the transpose on the TI59 and publish a comparison of results for the inverse of the transpose for the HP15C, HP41 and TI59. In the meantime I wanted to let everyone know that the supposed differences were the result of comparing apples and oranges. The confusion might have been avoided if I had published the Kahan 4x4 matrices in a more conventional format:
Test Inverse
6 1 3 1 5 6 23 9
2 0 1 3 11 13 50 20
2 1 0 1 7 8 31 12
3 2 1 0 1 1 5 2
One final comment. The success of iterative refinement with the HP15C and the HP28S makes me wish that there had been an equivalent capability with the HP41 Advanced Solutions Pac.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Palmer:
Palmer posted:
"Would you believe that both sets of HP15C 4x4 results are right?"
Yes, I knew ! Congratulations on your find ! I did likewise last night (12 hours ago), once I had a look at the original
Kahan's paper. I immediately noticed that Kahan's matrix was transposed ! I inverted it at once in my Brazilian HP15C and got your results !! :)
It seems I didn't notice that your original posting was listing the matrix by columns, instead of the expected roworder, so I keyed it in rowwise, as usual, and thus my 15C computed the transpose of Kahan's matrix, which amazingly, gives the correct inverse (if transposed, of course) but with 300% greater accuracy ! Seeing is believing ...
"As Valentin said in one of his
submissions the devil is surely in the details. [...] The confusion might have been avoided if I had published the Kahan 4x4 matrices in a more
conventional format."
Indeed ! Also, a book case of Murphy's Law at work. Normally I would have consulted the relevant Kahan's paper you mentioned, but having scores and scores of Kahan's papers, I didn't notice you were referring precisely to "Mathematics written in sand" (it could well be any of a number of similar papers dealing with matrices) and so I keyed in the matrix directly from your post, which featured it columnwise as stated.
"One final comment. The success of iterative refinement with the HP15C and the HP28S makes me wish that there had been an equivalent capability with the HP41 Advanced Solutions Pac."
Yes, in the case of the HP15C it's a rarely used function (MATRIX 6) but when you need it, it's quite convenient as it performs both a matrix multiplication *and* a matrix subtraction with a single, 1step instruction, using full 13digit accuracy.
And of course, a keen programmer can find many other advanced uses for it, even departing wildly from its original intended purpose.
Thanks for all your postings, Palmer, I've found this exchange very enjoyable and productive, even learned new unexpected things (such as different accuracies when inverting a matrix or its transpose). It's also very comforting to exchange worthwhile insights and ideas with someone who's not the stereotypical RPNblinded fanatic but can and does appreciate other means and other ways.
_{
(BTW, though Kahan's "Mathematics written in sand" is a truly awesome document if ever there was one, that I would very heartly recommend everyone (not just RPN fans) to read carefully, don't be "blinded" by the fact that Mr. Kahan is one of the world's authorities on the subjects discussed, the paper still has a number of bold statements that, in practice, may or may not hold. For instance, in page 21 of said document, Mr. Kahan boldly states:
} "Under no circumstances will [SOLVE] run indefinitely;
it always finds something, even if sometimes the
search takes a long time."
I'd love to know Mr. Kahan's definition of "a long time", but if it coincides more or less with mine or yours, you can trust me when I say that, for SOLVE's implementation as "written in sand" in the HP15C or HP71B silicon "sand brains", it actually means a very loooooooooooooooonnnnnnng time indeed for some extremely simple, even trivial cases.
So long that you'll run down many, many, many battery sets
waiting for the answer. Or perhaps you will be the one 'wearing down' with the passing decades, assuming the machine itself will last that long ... :) )
Best regards from Valentin Albillo.
Posts: 68
Threads: 1
Joined: Jul 2005
Hi Valentin,
I just want to make sure that I understand the concept of ULPs correctly. I had a look at the results you posted for the HP15C. I think that the number of ULPS for 0.999999997 should be 30 (you have it as 3) and the number of ULPs for 0.999999996 should be 40 (you have it as 4). When I enter these values on my HP12C and hit 'CLEAR PREFIX', I get 9999999960 and 9999999970 respectively. This seems to indicate to me that the ULPS should indeed be 30 and 40 for these values.
I persume that the HP15C is rounding these values for display and that if you hit 'CLEAR PREFIX', you will get ULP errors of between 25 and 34 for the displayed value of 0.999999997 and between 35 and 44 for the displayed value of 0.999999996.
Assuming that the ULPs for these figures are 30 and 40, this increases the ULPs sum for the HP15C from to 179 to 242.
I also tried inverting the test matrix on my Sharp EL5500III. Here's what I got:
5.000000002 11.00000000 7.000000003 1.000000000
6.000000002 13.00000001 8.000000003 1.000000001
23.00000000 50.00000002 31.00000001 5.000000002
9.000000004 20.00000001 12.00000000 2.000000001
This result has an RMS relative error (as defined by Palmer) of 4.547E10, which is approx. 15% of that of the HP15C value that I calculated as 3.0586E09, which I calculated from the results that you posted.
If I understand the concept of ULPs correctly, the ULP errors for the EL5500III are:
2 0 3 0
2 1 3 1
0 2 1 2
4 1 0 1
Summing this gives a total of 23 ULPs of error, or less than 10% the ULP error for the HP15C (assuming my understanding of ULPs above is correct).
I find the performance of the EL5500III very surprising, given the reputation of the HP15C. I fully expected the Sharp machine to have poorer performance. Of course, this is just one test case. I'm sure that other test cases behave differently.
One final note  that I hope is not too much off topic  in a previous post, you recommended the Sharp PC1475 that has 20digit percision. Do you know how this machine performs on this test?
Regards,
Eamonn.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi Eamonn,
Eamonn posted:
"I think that the number of ULPS for 0.999999997 should be 30 (you have it as 3) and the number of ULPs for 0.999999996 should be 40 (you have it as 4). [...] This seems to indicate to me that the ULPS should indeed be 30 and 40 for these values."
Absolutely correct. It was very late in the night when I was writing down these results (the HP15C has no I/O at all)
and I forgot to use f PREFIX (i.e.: "view full mantissa") with these two numbers, which being <1 do have their last digit not visible when displayed.
"Assuming that the ULPs for these figures are 30 and 40, this increases the ULPs sum for the HP15C from to 179 to 242."
Correct. I've checked the hidden digits and they are indeed 0's, so the Ulps come out as 30 and 40, respectively, and your 242 is the correct sum, still nearly 3 times smaller than Palmer's (Kahan's) results.
"I also tried inverting the test matrix on my Sharp EL5500III [...] Summing this gives a total of 23 ULPs of error, or less than 10% the ULP error for the HP15C [...]
I find the performance of the EL5500III very surprising, given the reputation of the HP15C. I fully expected the Sharp machine to have poorer performance."
Quite on the contrary. I'm just as keen a fan and a collector of SHARP machines as I am of HP ones. Beginning with the PC1211 (aka TRS80 Pocket Computer) they've produced such incredible machines as the PC1262 (Voyagersized), 1350 (4line x 24 char graphics display), 1421 (Financial BASIC), 1425 (Statistics BASIC), 1475 (matrix op., 2line LCD, BASIC, 20digit, 32 Kb), and of course your 1403H (aka EL5500III), to name but a few.
Their performance and quality have always been outstanding,
and they perform today as well as 20 years ago.
"in a previous post, you recommended the Sharp PC1475 that has 20digit percision. Do you know how this machine performs on this test?"
Yes. With that stunning 20digit precision it has no problem to deliver in excess of 10 correct digits (or 12, for that matter) for both this example and the 8x8 Hilbert matrix scalarlymultiplied by 360360.
If you like your SHARP EL5500III, you'd do well to get a SHARP PC1475. It has everything your machine has (matrix operations and all) plus 20digit computations and variables, and a wonderful 2 lines x 24 char dotmatrix display.
Thanks for your valuable contributions to this thread and
Best regards from V.
▼
Posts: 68
Threads: 1
Joined: Jul 2005
Valentin,
I will certainly keep an eye out for a PC1475, based on your recommendation. I share your admiration of the Sharp handhelds, aswell of course of the few HP machines I have had the opportunity to play with.
To complete the testing of the EL5500III, I also inverted the matrix from the Kahan paper and here are the results.
4.9999999980 5.9999999980 22.9999999900 8.9999999970
11.0000000000 13.0000000000 49.9999999900 19.9999999900
6.9999999980 7.9999999980 30.9999999900 12.0000000000
0.9999999996 0.9999999996 4.9999999980 1.9999999990
Interestingly, in this case the RMS relative error decreases a little from 4.5475E10 to 3.3907E10 while the sum of the ULP errors increases a little, from 23 to 26. Amazingly, both are better than the HP15C results that have been posted, by a factor of more than 20.
Eamonn
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Eamonn:
Eamonn posted:
"I will certainly keep an eye out for a PC1475, based on your recommendation. I share your admiration of the Sharp handhelds,
aswell of course of the few HP machines I have had the opportunity to play with."
You'd do well to keep both eyes peeled for a SHARP PC1475, it's certainly an awesome machine, both functionally and phisically, here's a picture of one of mine (I've got two):
My SHARP PC1475
The result for Sqrt(5) on the LCD display was computed and displayed by the doubleprecision, 20digit square root
function available in this machine. How's that for accuracy, uh ? :)
As for HP's, I have the opportunity to 'play' with most of them, if not all (I think the HP95C is the one and only I've never played with, and that includes all three models of HP94, the HP70, and the HP01 goldplated watch). Some I like, some I despise. The last batch of KinHPo crap certainly belongs to the later
group, but then that's not HP's, actually.
"To complete the testing of the EL5500III, I also inverted the matrix from the Kahan paper and here are the results [...] Amazingly, both are better than the HP15C results that have been posted, by a factor of more than
20."
Why amazingly ? Eamonn, it seems to me that you've got
some kind of "inferiority complex" re SHARPs vs. HPs.
You must do some group therapy with some other SHARP fans,
like myself, and you'll get cured eventually. Just for
starters, repeat with me: "In the good old times,
anything HP did Ok, SHARP did as well or better". Repeat
it mantralike for a while, and you'll feel better.
Jokes aside, my SHARP PC1350, which has no builtin
matrix functions, does return the *exact* inverse (error
= 0) using a simple 4line BASIC routine, in 8 seconds flat.
The PC1475 does the same, only with 10 extra zeroes at
the end of each number.
Best regards from V.
▼
Posts: 118
Threads: 17
Joined: Oct 2007
Jul 05, 2004
Hi Valentin,
Just for fun, what result do you get with your sharp computer if you compute '' exp ( pi * sqrt(163)) ''. I understand this strange number has very interesting properties, including rouding off as an integer for any computation done with less than 20 significant digits.
Thank you for your kind attention and Best Regards from
Antoine M. '' Kermit '' Couëtte
▼
Posts: 785
Threads: 13
Joined: Jan 2005
"'' exp ( pi * sqrt(163)) ''.
I understand this strange number has very interesting properties,
including rouding off as an integer for any computation done with less than 20 significant digits"
Using the LongFloat library on my HP 49g+ (with 100 'DIGITS' STO) I got the following (edited):
262537412640768743,999999999999 25007259719818568887935385633733699 08627075374103782106479101186073108
"VPN"
▼
Posts: 118
Threads: 17
Joined: Oct 2007
Jul 06, 2004
Thank you VPN !
Strange number, isn't it?
Kermit :)))
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, VPN:
The last digits should be: "73129" (truncated) instead of your "73108" (rounded ?), so you've got an error of 21 ULPs.
Not too bad.
If you want to have some extra fun with your LongFloat library, try and compute the square root of 308642 to, say, 45 digits or so, and see if you can explain the result on your own, without looking it up like mad in the Internet.
If you do succeed, you might want to try your calculator's long integer capability by multiplying these three prime numbers together:
611509954376459299030014869
* 912070930867832438835716332271
* 1394515626656963173831296487834723 = ?
Best regards from V.
▼
Posts: 305
Threads: 17
Joined: Jun 2007
Valentin Albillo says:
"If you want to have some extra fun with your LongFloat library, try and compute the square root of 308642 to, say, 45 digits or so, and see if you can explain the
result on your own, without looking it up like mad in the Internet."
I won't explain the result, which is the presence of quite a few repeating digits in the square root of 308642, but I will offer some relatives of SQRT(308642)
SQRT(278) and SQRT(27778) are the little brothers.
SQRT(308641975308641975) is the daddy.
SQRT(308641975308641975308642) is the granddaddy.
SQRT(444444), or square root of an integer consisting of any even number of "4" digits will give a result with a bunch of repeating digits in the result.
The product of the three large primes is a long string of "7" digits with a single "5" digit near the middle.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Rodger:
Thanks for your post but for the sake of completeness, I'm giving here explicitly the results you
mention, for the benefit of those unable to calculate them to the required high precision:
SQRT(308642) =
555.5555777777773333333511111102222222719999970133335
SQRT(278) = 16.673332000533066
SQRT(27778) = 166.6673333320000053333066668159991
SQRT(308641975308641975) =
555555555.555555555 2
777777777777777777 08
333333333333333 2986
11111111111111 0894097
222222222222 0703124
99999999999 886067708
333333333 2438151041
66666666 59393310546874
99999 39388699001736111
SQRT(308641975308641975308642) =
555555555555.5555555555555
77777777777777777777777777
3333333333333333333333333 5
111111111111111111111111 0
2222222222222222222222222 71
99999999999999999999999 701
3333333333333333333333 5210
666666666666666666666 54464
000000000000000000000 8135
11111111111111111111 0557923
5555555555555555555 9377578
666666666666666666 39912504
8888888888888888 9078226033
7777777777777777 64253696
000000000000000000 973733887
9999999999999999 2940429312
000000000000000 51493339135
99999999999999 622382179669
3333333333333 61157804305066
SQRT(444444) = 666.6663333332499999583333
And, finally:
611509954376459299030014869
* 912070930867832438835716332271
* 13945156266569631738 =
777777777777777777777777777777777777777
777777777775
777777777777777777777777777777777777777
as for the reasons why SQRT(308642) and the others come out like that, I'll leave it as an exercise for the readers (quite easy, actually).
Thanks for your interest and
Best regards from V.
▼
Posts: 305
Threads: 17
Joined: Jun 2007
I thought I would leave it as an exercise, also!! Surely at least one other person might have something to say!
After I worked on it, I did go looking on the web to see what might have been said, but all I found with a cursory search were the places where you had posted the problem in Spanish.
Edited: 15 July 2004, 1:11 p.m. after one or more responses were posted
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Rodger posted:
"Surely at least one other person might have something to say!"
Don't hold your breadth ...
"all I found with a cursory search was the places where you had posted the problem."
Best regards from V.
Edited: 16 July 2004, 4:31 a.m. after one or more responses were posted
▼
Posts: 305
Threads: 17
Joined: Jun 2007
When I posted, I didn't have the web page where you had posted the problem immediately available, and I couldn't remember whether it had been in Spanish or Portugese (I knew it had been one of those), so I said "another language".
I have edited the posting to correct my grammar and changed "another language" to "Spanish".
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Rodger:
Rodger postes:
"I have edited the posting to correct my grammar and changed "another language" to "Spanish"."
Thanks for caring. In the same mood, I've edited my previous post to remove any references to languages and such.
Best regards from V.
Posts: 785
Threads: 13
Joined: Jan 2005
X SNIP X
try your calculator's long integer capability by multiplying these three prime numbers together:
611509954376459299030014869
* 912070930867832438835716332271
* 1394515626656963173831296487834723 = ?
================================================
"77777777777777777777777777777777777777777777777777
5
777777777777777777777777777777777777777"
edited for easier reading
"VPN"
Posts: 785
Threads: 13
Joined: Jan 2005
X "LongFloat library, try and compute the square root of 308642 to, say, 45 digits
=============================================
"555555577777777333333351111110222222271999997.E42"
 no Xplanations 
you tell me  oh Jedi Master...
(VPN)
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, VPN:
VPN wrote:
" no Xplanations  you tell me  oh Jedi Master..."
You're welcome, my padawan learner. The "key" to the mistery of SQRT(308642)'s uncanny initial regularity lies in the fact that 308642 is very close to the square of 5000/9.
Actually, we have:
(5000/9)^2 = 25000000/81
while
308642 = 25000002/81
so it misses the target by just 2 parts in 25 million, so to say. This being so, we proceed to compute its square root this way: we have
308642 = 25000000+2 = 25000000 * (1 + 2 )
81 81 25000000
and thus
SQRT(308642) = SQRT(25000000 * (1 + 1 ))
81 12500000
= SQRT(25000000 ) * SQRT (1 + 1 )
81 12500000
= 5000 * SQRT(1 + 1 )
9 12500000
And now, using the classic Taylor series expansion for SQRT(1 + x), with x = 1/12500000:
= 5000/9 * (1 + 1/25000000  1/1250000000000000 +1/31250000000000000000000  ...)
= 555.555555555555555... * (1 + 4E8  8E16 + 32E24  ... )
So, in the end, we are just multiplying a highly regular, patterned number (555.555555555...) times another highly regular, patterned and (initially) lagunar number:
= 555.555555555555555...
* 1.000000039999999200000031999998 ...
so it should come as no surprise that the end result is (initially) highly patterned as well:
= 555.555577777777333333351111110222222271999997...
And that explains it all. Notice that I've said "initially" in a number of places. That's because after a while, the lagunarity of the second factor gets lost:
= 1.000000039999999200000031999998400000089599994624000
337919978035201464319900426246879641118425122080683
and consequently, the resulting product (i.e.: the square root of 308642) ceases to be patterned as well:
= 555.555577777777333333351111110222222271999997013333
521066654464000813511055792359377578399125067822
A real pity, but unavoidable nevertheless.
May the force be with you and best regards from V.
Edited: 16 July 2004, 6:29 a.m.
▼
Posts: 305
Threads: 17
Joined: Jun 2007
What is a lagunar number?
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Rodger posted:
"What is a lagunar number?"
My mistake, a typo. I meant "lacunar" instead of "lagunar".
And in case you're not familiar with this word, here are some definitions:
Lacunar numbers:
Numbers with ``very sparse'' nonzero digits in some
base representation.
From Websters Dictionary, you have:
lacuna: (noun) A blank gap or missing part.
lacunar: (adjective) Pertaining to, or having, lacunae
The second factor is:
= 1 + 4E8  8E16 + 32E24  ...
= 1.0000000[4]0000000[8]000000[32]00000[...]
where you can see the "digits" [4], [8], [32], amid a number of "blank gaps" (i.e.: lacunae) formed by zeros.
= 1.000000039999999200000031999998 ...
Best regards from V.
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Antoine:
This number is old hat to any mathematician worth his/her salt. It's informally called 'Ramanujan Constant', you can read about it at this URL:
Ramanujan Constant
As for the results with my SHARPs, singleprecision machines such as my SHARP PC1350 give this result:
while doubleprecision ones, such as my SHARP PC1475 just give the precise integer result.
If you're interested, this is the list of exponents which give results very close to integers (known as Heegner numbers), you might want to try and calculate the resulting nearinteger value:
1, 2, 3, 7, 11, 19, 43, 67, and 163.
Best regards from V.
▼
Posts: 118
Threads: 17
Joined: Oct 2007
Jul 07, 2004
Thank you Valentin,
I dug in the Internet and read your earlier Challenge #4 which among other items gives information on exp(pi*sqrt163).
As former PPC USA member (# 10121), I still keep ( mostly for the emotion of it rather than for daily or even monthly use ) the entire collection of PPC CALCULATOR JOURNAL + CHHU in four big binders and I remember very well your quite frequent contributions at that time. Some things never change, since you keep being so enthusiastic!!!
Congrats, and Best Regards
Antoine M. "Kermit" Couëtte
