How do I answer this?



#97

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


#98

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)

#99

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 HP-15C 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" HP-15C 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."

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.

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 1970s-1980s with a couple from early-to-mid '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 4-level stack with T-copy down and a Last-X 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 formula-entry 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 T-copy-down 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 human-factors 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 floating-point math and related issues.

By contrast, many TI calcs of late 70s-early 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/ti-accry.htm

As the TI calculator market seems to be schoolteacher-driven, it has avoided the people who do real math with real calculators. And yet the high-end TI calcs (like TI-89) 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


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.

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 quasi-religious. 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 TRS-80 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 HP-67 and HP-97. But, Bill Wozniak, the co-inventor 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 sub-expressions 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 TI-30.

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 TI-59 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 TI-59. Near the end of his paper he presented an example of the inversion of a 4x4 matrix on the HP-15. He did not present the results for the TI-59. I wondered about that. I did the inversion on my TI-59. With all its computational warts the TI-59 yielded errors in the solution which were a factor of 400 smaller than those reported for the HP-15. 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."


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 feature-laded 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 one-time 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 front-end (without some kinda 41 emulation module, etc.) That would've been a fun machine!


Bill Wiese

San Jose CA


"I was rather disappointed that the HP71B machine didn't have an RPN calc front-end 
(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)

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 "high-level" 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 climb--and 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

Bill wrote: "I was rather disappointed that the HP71B machine didn't have an RPN calc front-end (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.

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 HP-67 and HP-97."


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.


Hi Valentin,


I wonder what you think of the other thing Palmer mentioned: regarding "inversion of a 4 x 4 matrix with the Ti-59 having smaller errors than those found in the results obtained with an HP-15c.


Regards,


Bill


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 Ti-59 having smaller errors than those found in the results obtained with an HP-15c."


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 HP-15C 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.


Hi again,

It is, as I rather suspected, that the "devil is in the details"!

Regards,

Bill


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.

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 (ML-02) 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.


You quoted from the instrucions for the ML-02 program in the TI-59 Master Library as follows:

"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.

Before you get too concerned about the the admitted errors which may occur with the determinant calculation in the ML-02 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 HP-41C 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                         HP-41 Math Pac - 10 digit machine

-200.0000002 HP-41 Advantage Module - 10 digit machine

-199.9999999976 TI-59 Master Library ML-02 - 13 digit machine with warts

-199.999999999 HP-28S - 12 digit machine

-200.00000000011 TI-85 - 14 digit machine

Is that telling you anything?

The displays of the TI-59 and TI-85, like the display of the HP-41 Math Pac with the HP-41 in Fix 4, indicate that the answer is -200, when the actual value inside the machine is in error by a small amount.


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, double-precision numbers with 32-digit mantissa (and even more) in portable computing devices like calculators (I am talking about their resident O.S., not an actual floating-point processor) or PDA's without speeding them down too much, we are discussing valid subjects like 12-, 13- and 15-digit 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 13-digit display against a 10-digit LCD in the HP41 is something that must be considered. I know that the HP41 computes 12-digit mantissa numbers while in microcode, but I don't know how do numbers are held by the TI58/59 functions. Are they also 13-digit 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 13-digits 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 LED-based 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 5-digit 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.


Some of the things you may be interested to know about the TI-59 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 SR-52, 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 non-commutative multiply starting with the TI-66 (or maybe it was the TI-55II).


5. TI switched to a conventional guard bit with rounding starting with the TI-95 (or maybe it was the TI-68).


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 13-digit 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 TI-95 (or maybe it was the TI-68).
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)


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 TI-55II, TI-57LCD, and BA-55. It was so bad that when they finally fixed it and came out with a TI-55III you could send in a TI-55II and get a TI-55III in the return mail, no questions asked. The same keyboard was used on the TI-88, which was to be TI's answer to the HP-41, but which didn't go to production.


Yeap, you're right.

About HP, the "new family" (Kinpo) ones speak for themselves...

Cheers.

Luiz (Brazil)

"
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`

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

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 ;)


[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 HP-32/33 or 48/49
(VPN)
PS: I swing both ways in science/religious RPN/ALG,
but otherwise I'm straight ;-)


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


I found myself the other day, unexpectedly having to defend the theory of evolution.....and the person (a co-worker from another office) had presented a puzzle regarding the chances of a "single celled organizm" evolving----which he assessed (without proof) to be essentially zero. So I constructed an ad-hoc 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 space-time (which of course dramatically improves our chances to exist!) etc etc. (no numbers involved and no true calculations--just an assessment of the "boundary conditions").


And of course somewhere in there the concept of intelligence, reason, etc had to be developed----the big bone of contention for this other fellow was the "ape-man" etc. And so of course this brought up consciousness, or the existence of self-awarenesss, to which I asked rhetorically, "so when you die, does your consciousness just go **poof! Yes, why not--do 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


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 >>

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 12-long 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 single-digit 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 HP-25, 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 command-line 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.


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)

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 12-long 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 command-line 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


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.3-9.5)+(-6.3-3.2)*(2.4-5.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.3-9.5)+(-6.3-3.2)*(2.4-5.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 mid-expression 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 re-typing 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.


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 key-in 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.

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 type---but not formula entry like Valentin's) and I got 881.6232 the first time (this is one order of magnitude smaller than Valentin---did not do it again). Then I did it again on the 11-c, 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 RPN-only 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 down---generally 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 Algebraics--which are actually postfix for everything except the arithmatic opperators---and 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, "oh--I 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 time--but not always. Period.


In fact, I like algebraic better for doing accounting---as it mimics the keyflow of the "adding machine logic" (except that you are infix--except it feels the same, as the last "+" which is open, has effectively finished the last addition, too--if you don't know what I'm talking about, don't worry).


regards,

Bill

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.3-9.5)+(-6.3-3.2)*(2.4-5.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 mid-expression 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 re-typing 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


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 "ad-hominem" attack, labeling me as "biased-against-RPN" ? 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 4-level RPN vs. true algebraic and now you introduce n-level 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 multi-level 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 top-of-the-line, 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 4-level wasn't enough (you just were "pretty sure", not downright positive; that would require carefully pre-scanning the expression, isn't it ?), while I can compute said expression without even batting an eyelid even in the *lowest*, bottom-of-the-line 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 "ad-hominem" 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.


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

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 bottom-of-the-line 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 Triumph-Adler 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 re-type 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 re-typing 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 down---generally 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... :-)


.

I just saved this answer to HD (as a web page)

I could have NOT possibly said it any better myself

(V+P*N)

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.3-9.5)+(-6.3-3.2)*(2.4-5.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

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.3-9.5)+(-6.3-3.2)*(2.4-5.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.3-9.5)+(-6.3-3.2)*(2.4-5.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:

  1. the example problem was symmetrical -- a product of two long, identically-constructed terms, each consisting of a sum of two products of two-element sums -- alles klar?

  2. The expression utilized rules of mathematical precedence to allow omission of several more sets of parentheses.

  • The 32SII "classic 4-element RPN" worked well if one had the sense and foresight to store the first major sum in a register. A 4-element stack is necessary and sufficient to calculate each major sum.

  • The HP-20S algebraic worked correctly, but entering all those "( )" slows the user down. No thinking required, though!

  • The HP-10B and HP-17BII (in algebraic) give incorrect answers unless the user inserts extra parentheses at the required places.

  • The HP-48G 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 fx-115MS "S-V.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 adding-machine calculators do, to use Valentin's restaurant example.

-- Karl S.

Edited: 1 July 2004, 1:40 a.m.


Karl Schneider gave a good summary, with one mistake:



--

* The $15 Casio fx-115MS "S-V.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)(5-2 =


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.


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 fx-115MS because I saw that it had complex-number handling, and I wanted to see how well it was implmented in a unit costing only $15. Also, I have a 1981 fx-3600P (which served me well until I bought my HP-15C 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 2-line dot-matrix/7-segment LCD readout, but not at all impressed by its poor product-design engineering. Whereas the fx-3600P was a no-nonsense tool like the HP's, this fx-115MS 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 fx-3600P, shifting to radian-measurement mode is simply "[MODE] 5" (which is printed on the face), and you get a nice "RAD" annunciator. On the fx-115MS, 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 linear-equation solver (limited to 2 or 3 unknowns) is utterly befuddling to one who hasn't read, understood, and remembered the instructions in the fold-out manual.

  • Lack of Consistency -- On the fx-115MS, 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 fx-115MS,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 HP-15C 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


  • Hi Karl, et al:

    You can apply pretty much everything you said about the Casio fx-115Ms 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 co-workers 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 HP45--and she gave it to me, knowing how much of an HP collector I have become--a very generous gift, yes! Question is, how on earth to properly reciprocate?

    Regards


    Bill


    Hi, Bill:

    Bill posted:

    "she gave it to me, knowing how much of an HP collector I have become--a 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.

    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.

    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 low-level algebraic mode.


    It's my observation that even in the last few years,

    I could do simple (and more complex) calculations faster
    with my HP-41 or HP-48 than my colleagues with
    their Casios, or even with their four-bangers.

    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.

    Four-bangers 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 HP-41 or HP-48
    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 RPN-like 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 HP-28C.

    And that's an important point: You have the choice of either
    entering your numbers RPN-like or in an algebraic
    manner, at least with many Saturn-based HP calcs,
    like the HP-17BII, HP-28, and HP-48 series.

    Ooops, I nearly forgot the hp33s, which is not a
    Saturn-based machine, strictly speaking.

    Regards,

    Raymond

    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

    Ti no longer releases a pocket programmable either. They should.

    If Ti were to re-release a Ti-66 with RPN and a softclick, you would also be happy. Actually, a Ti-67 with better keys and an RPN option would make us all happy. Of course if they incorporated more of your ideas, even better.

    Before presenting some detailed matrix results I want to add something to those comments that suggested that the HP-71 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 HP-41, and of course included a discussion of the superiority of RPN. Then, he made a pitch for the HP-75 (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 HP-41, otherwise you could use the 75.

    Why did I use a TI-59? 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 TI-59, 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 TI-59. When the HP-41 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 TI-59.

    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 so-called "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 TI-95 in which a TI machine finally yielded faster results than those achieved with the H-41. Gene could not rest until he had coached someone into converting the old HP-41 program for use on an HP-42 and once more claiming the pi finding competition for the HP product line. That dedication reminded me of super-programmer Roger Hill's comment during the calendar printing competition when he noted that the "friendly competition" looked a lot like "all-out war".

    The following table compares the column by column results reported for the HP-15 with those obtained with the HP-41 Math Pac and with the ML-02 program in the Master Library of the TI-59. The relative error for an element of the solution matrix is defined as (calculated - exact)/exact.

     Test       Inverse                  HP-15                  HP-41                           TI-59
    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.004E-08 5.40E-09 2.41E-11

    The RMS relative error for the elements of the inverted matrix for the HP-15 as reported in the Kahan paper is 416 times larger than that from the ML-02 prgram of the TI-59 Master Library. The RMS relative error for the HP-15 is a factor of two worse than the results obtained with the HP-41 Math Pac.

    The TI-59 results which are displayed or printed from ML-02 would suggest that it had arrived at an exact solution. But every serious user of the TI-59 knows that the displayed value is a rounded value derived from the 13 digit display register. The value for the TI-59 in the table above were extracted from the display register.


    The text of the Kahan paper indicates that the results for the HP-15 were obtained by entering the test matrix and performing the inverse by using 1/x. The paper mentions iterative refinement as described on pages 119-121 of the HP-15C Advanced Functions Handbook but doesn't present any results. I don't have an HP-15C so I can't provide the results with iterative refinement. I do have an HP-28S. One cycle of iterative refinement as defined on pages 68-69 of the HP-28S 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 HP-15C inversion recovers three correct significant figures. The RMS relative errors for that problem for several machines are

    4.134E-04 HP-41 using the Advantage MATRX routiine

    1.818E-05 TI-59 using ML-02

    7.249E-06 TI-85

    1.309E-06 HP-28S using iterative refinement from page 69 of Reference Manual


    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 TI-59, of course, benefits from its 13 digits at every step.

    Werner

    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 HP-71B (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=A-B
    160 DISP FNORM(A)

    result is 1.1E-10.

    BTW, see how easy are matrix calculations on a good ALG machine :-)

    J-F


    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.8E-11, close to TI59 accuracy.

    J-F


    Hi, Jean François, Palmer and all interested in this thread:

    Jean François posted:

    "I just tested the HP-71B (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.8E-11, 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 HP-71B/Math ROM can run rings around the TI-59 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=A-B @ 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 TI-59 ? The moral: Never, ever, subestimate past HP's ingenuity :-)

    Best regards from V.


    Edited: 29 June 2004, 12:35 p.m.


    I don't have a TI-71 so I can't respond directly. The HP-28S with one iteration of refinement also gets the exact answer to the 4x4 problem.


    The HP-28S 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 sub-Hilbert, (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 HP-49 and TI-89 are able to solve both of these problems exactly. I would be interested to know what the HP-71 can do.


    Hi again, Palmer:

    Palmer posted:

    "I don't have a TI-71"

    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 HP-28S 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 HP-49 and TI-89 are able to solve both of these problems exactly. I would be interested to know what the HP-71 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 HP-71B has no symbolic math capabilities nor an Exact mode, so it will perform operations with 15-digit mantissas and in such anomalous, ill-conditioned 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.


    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.

    Thanks Valentin, now I remember that SYS gives more accurate answer than the INV command. Also for early HP-48SX (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, ...

    J-F


    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.


    >> "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 HP-48SX rev.A (at least). I don't think that the HP-71B MathROM has the same problem.

    The only problem I was told about the HP-71 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).

    J-F

    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

    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 HP-15C are utterly wrong !.

    Of course I've noticed that he explicitly states that he doesn't own an HP-15C 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 HP-15C (verified in all four physical HP-15C's I own, i.e., 3 USA-made 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 HP-15 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(C-A) = 0.000000325
    FNORM(C-A) = 0.000000214

    His quoted results:

        RNORM(C-A) = 0.000001048
    FNORM(C-A) = 0.000000689

    also roughly 300% larger than the actual ones.

    And last but not least, the HP-15C does allow for refinement of the solution by using the built-in, 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 HP-15C, 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 = I-B*A
    RCL MATRIX A
    MATRIX 6 compute the residual R = I-B*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.


    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


    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 HP-15C, 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 not-ill-behaved matrix, computing as it does to far greater precision than a real HP-15C (or HP-71B, 42S, etc., for that matter).

    However, don't get blinded by that expected success. As soon as you step out of the small, well-conditioned matrices into larger, ill-conditioned 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.737E-33 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 non-invertible.

    Nice to 'hear' from you, and

    Best regards from V.


    Edited: 30 June 2004, 9:52 a.m.


    Hi Valentin, nice to hear from you ! :)
    Ho, I have no doubt that it should be possible to fail Lygea's simulator with ill-conditionned matrixes - I studied them, well, a long time ago, in 1991... And at that time even the HP-48SX 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

    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.


    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.


    Now I get it. Thanks.

    I like when I don't understand. It means I'm about to learn something.

    As I clearly stated in my presentation of the HP-15C 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 HP-15C. 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 e-mail 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 hp-15c 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 HP-15C 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 HP-15C 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 HP-15C which would yield results less accurate than what are possible with the machine.


    Hi, Palmer:

    First of all, thanks for answering my concerns about the HP-15C 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 e-mail 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 HP-15C 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 pre-production unit (he probably had one of the very first HP-15C prototypes ever produced). I'll try to get other HP-15C 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 HP-15C 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 HP-15C are gifted, who knows ? :-)

    A final advice, if you would: as I understand you're working in some project re the friendly HP-TI 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 non-reproducible, provably erroneous results. Unlikely perhaps, but a rigorous approach is mandatory for scholar-type 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.


    Would you believe that both sets of HP-15C 4x4 results are right?

    I had trouble believing that there were HP-15C's which gave different answers to the same problem although I knew that there were some minor differences between early and late model HP-11C's. I still didn't have an HP-15C to work with but then I remembered that Gene Wright had loaned a HP-41 ADVANTAGE Advanced Solutions Pac to me, and that I had been told that the matrix routines mirrored the HP-15C 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 HP-15C and as published in my comparison of the HP-15C, HP-41 Math Pac and TI-59 ML-02 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 HP-41 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 HP-28S gets six of the elements of the inverse of the transpose exactly right. The HP-28S 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 TI-59 and publish a comparison of results for the inverse of the transpose for the HP-15C, HP-41 and TI-59. 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 HP-15C and the HP-28S makes me wish that there had been an equivalent capability with the HP-41 Advanced Solutions Pac.


    Hi, Palmer:

    Palmer posted:

    "Would you believe that both sets of HP-15C 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 HP-15C and got your results !! :-)

    It seems I didn't notice that your original posting was listing the matrix by columns, instead of the expected row-order, so I keyed it in row-wise, 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 column-wise as stated.

    "One final comment. The success of iterative refinement with the HP-15C and the HP-28S makes me wish that there had been an equivalent capability with the HP-41 Advanced Solutions Pac."

    Yes, in the case of the HP-15C 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, 1-step instruction, using full 13-digit 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 RPN-blinded 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 HP-15C or HP-71B 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.

    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 HP-15C. 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 HP-12C 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 HP-15C 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 HP-15C from to 179 to 242.

    I also tried inverting the test matrix on my Sharp EL-5500III. 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.547E-10, which is approx. 15% of that of the HP-15C value that I calculated as 3.0586E-09, which I calculated from the results that you posted.

    If I understand the concept of ULPs correctly, the ULP errors for the EL-5500III 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 HP-15C (assuming my understanding of ULPs above is correct).

    I find the performance of the EL-5500III very surprising, given the reputation of the HP-15C. 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 PC-1475 that has 20-digit percision. Do you know how this machine performs on this test?

    Regards,

    Eamonn.


    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 HP-15C 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 HP-15C 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 EL-5500III [...] Summing this gives a total of 23 ULPs of error, or less than 10% the ULP error for the HP-15C [...] 
    I find the performance of the EL-5500III very surprising, given the reputation of the HP-15C. 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 PC-1211 (aka TRS-80 Pocket Computer) they've produced such incredible machines as the PC-1262 (Voyager-sized), 1350 (4-line x 24 char graphics display), 1421 (Financial BASIC), 1425  (Statistics BASIC), 1475 (matrix op., 2-line LCD, BASIC, 20-digit, 32 Kb), and of course your 1403H (aka EL-5500III), 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 PC-1475 that has 20-digit percision. Do you know how this machine performs on this test?"
    
    Yes. With that stunning 20-digit 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 scalarly-multiplied by 360360.

    If you like your SHARP EL-5500III, you'd do well to get a SHARP PC-1475. It has everything your machine has (matrix operations and all) plus 20-digit computations and variables, and a wonderful 2 lines x 24 char dot-matrix display.

    Thanks for your valuable contributions to this thread and

    Best regards from V.


    Valentin,

    I will certainly keep an eye out for a PC-1475, 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 EL-5500III, 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.5475E-10 to 3.3907E-10 while the sum of the ULP errors increases a little, from 23 to 26. Amazingly, both are better than the HP-15C results that have been posted, by a factor of more than 20.

    Eamonn


    Hi, Eamonn:

    Eamonn posted:

    "I will certainly keep an eye out for a PC-1475, 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 PC-1475, it's certainly an awesome machine, both functionally and phisically, here's a picture of one of mine (I've got two):

    My SHARP PC-1475

    The result for Sqrt(5) on the LCD display was computed and displayed by the double-precision, 20-digit 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 HP-95C is the one and only I've never played with, and that includes all three models of HP-94, the HP-70, and the HP-01 gold-plated 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 EL-5500III, I also inverted the matrix from the Kahan paper and here are the results [...] Amazingly, both are better than the HP-15C 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 mantra-like for a while, and you'll feel better.

    Jokes aside, my SHARP PC-1350, which has no built-in
    matrix functions, does return the *exact* inverse (error
    = 0) using a simple 4-line BASIC routine, in 8 seconds flat.
    The PC-1475 does the same, only with 10 extra zeroes at
    the end of each number.

    Best regards from V.


    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


    "'' 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"


    Jul 06, 2004


    Thank you VPN !
    Strange number, isn't it?

    Kermit :-)))

    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.


    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.


    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.


    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


    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


    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".


    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.

    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"

    X "LongFloat library, try and compute the square root of 308642 to, say, 45 digits
    =============================================
    "555555577777777333333351111110222222271999997.E-42"
    - no Xplanations -
    you tell me - oh Jedi Master...
    (VPN)

    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 + 4E-8 - 8E-16 + 32E-24 - ... )

    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.


    What is a lagunar number?


    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'' non-zero 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 + 4E-8 - 8E-16 + 32E-24 - ... 

    = 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.

    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, single-precision machines such as my SHARP PC-1350 give this result:

    while double-precision ones, such as my SHARP PC-1475 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 near-integer value:

            1, 2, 3, 7, 11, 19, 43, 67, and 163.  

    Best regards from V.


    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


    Possibly Related Threads...
    Thread Author Replies Views Last Post
      TI-36X Final Answer Matt Agajanian 0 453 08-31-2013, 08:40 PM
    Last Post: Matt Agajanian
      [HP-Prime CAS] Automatic Simplification (Direct Answer) CompSystems 6 1,117 07-26-2013, 07:20 PM
    Last Post: Gilles Carpentier
      The answer to the second semi-mathematical puzzle Mike Reed 3 749 02-18-2013, 02:40 AM
    Last Post: Derek Walker (UK)
      Answer to Mathematical Puzzle Mike Reed 2 667 02-08-2013, 12:11 AM
    Last Post: LHH
      Wrong answer when evaluating log(10^-12) Daniel Greenidge 4 855 01-26-2012, 05:54 PM
    Last Post: Daniel Greenidge
      [edited] from the HHC email list, what is the proper answer to 8 ENTER 3 divide 2 divide on 10 digit calc Gene Wright 10 1,506 10-02-2011, 01:07 PM
    Last Post: Dieter
      HP-12c, November 25, 4046, answer Don Shepherd 2 586 12-04-2010, 08:46 AM
    Last Post: Thomas Klemm
      Bobby Schenk Yacht Module; Answer from Bobby himself Geir Isene 17 2,017 11-17-2010, 11:28 AM
    Last Post: Walter B
      HP 41C data storage integrated circuit swapping: Maybe Eric could answer this ;-) Geoff Quickfall 19 2,406 03-18-2010, 05:18 PM
    Last Post: Eric Smith
      HP41 picture: the answer from HP Vieira, Luiz C. (Brazil) 21 2,392 11-19-2006, 09:33 PM
    Last Post: Fred Lusk (CA)

    Forum Jump: