ANSWERS to "Quiz: HP Voyagers"


Here are my answers to the quiz I posted earlier today (subject: "Quiz: HP Voyagers", 29 Aug 2005, 10:21 p.m.)

The are correct to the best of my knowledge, and I do have a working unit and manual for each model in front of me. I have no excuse for any mistakes here!

I may not have stated several of the questions quite specifically enough, but declined to edit the quiz after posting.

1. Which model(s) provide all twelve conditional tests?

Answer: The 15C.

By "conditional tests", I refer only to those six possible comparisons of a full floating-point value against 0.00 or another floating-point value, for a total of twelve conditional tests. I did not intend to include flag comparison, bit comparison, or loop-counter functions (which also perform a comparison when invoked).

The complete set is
x<0, x<=0, x=0, x!=0, x>=0, x>0, x<y, x<=y, x=y, x!=y, x>=y, x>y.

The 12 tests were provided by placing only two tests on the keyboard, then giving access to the remaining ten via the function TEST, followed by a one-digit code 0-9. This setup used only three keyboard positions.

2. Which model(s) provide only eight conditional tests?

Answer: The 11C and 16C.

The set of eight comparisons is identical to that in the HP-34C, omitting x<=0, x>=0, x<y, and x>=y from the complete set of 12.

The challenge of adding to the 15C these four tests missing from the 11C was ironically re-visited nine years later when the Pioneer HP-32SII was created from the HP-32S.

3. Which model(s) provide only two conditional tests?

4. Which model(s) do not provide insert/delete program editing?

5. Which model(s) do not provide a "delete digit" function?

6. Which model(s) do not provide any loop-counter functions?

Answer to 3, 4, 5, and 6: The 10C and 12C.

These two models had the rudimentary programming paradigm that was introduced in the short-lived HP-55 of the 1970's. Only overwriting of programmed instructions was allowed -- no insertions or deletions that make programming useful.

Not provided on the 10C and 12C were loop-counter functions (called DSE and ISG on the 11C and 15C; DSZ and ISZ on the 16C). Only two condtional tests (x<=y and x=0) were provided on the 10C and 12C.

These models also lacked the convienient "delete digit" function and introduced on the predecessor HP-41C. "delete digit" is denoted as a backarrow on the 41C, 11C, and 15C; it is denoted as as "BSP" (backspace) on the 16C. In program mode, "delete digit" serves as "delete line".

In my opinion, this limited programming paradigm ought to have been abandoned, rather than carried forward on new lower-end models. The 10C might have found a niche as a non-programmable with more functions.

7. Which model(s) provide Solve, Integrate, matrix functions, and functions using complex-valued inputs?

Answer: The 15C.

Addition of this functionality to the already-capable 11C was the main design objective of the 15C. Solve and Integrate had already been introduced on the 34C, but the robust matrix and complex-number functionality was unprecedented.

To add all this capability, in the same package and hardware of the 11C (whose keyboard positions were already fully-occupied) was an impressive achievement. With some sharp thinking, all the functionality was added, even as the keyboard layout was slightly improved!

An excellent HP Journal article from 1983 (available on the MoHPC CD/DVD set) describes the development of the 15C.

8. Which model(s) provide an "exchange with memory register" function?

Answer: The 11C, 15C, and 16C.

The 11C and 16C offered x<>(i) and x<>I, which exchanged x direclty with the I register or indirectly with the numbered register referenced in I. The 15C offered an open-ended "x<> ", that could be completed with I, (i), or any numbered register 0-9 or .0-.9 This gave more functionality, saved one keyboard position, and improved keyboard layout.

9. Which model(s) do not provide trigonometeric functions?

Answer: The 12C and 16C.

HP's philosophy has been not to include unnecessary functionality in any model designed for a particular purpose. Trig functions are rarely needed in basic finance and computer-science tasks.

10. Which model(s) do not provide logarithmic or exponential functions?

Answer: The 16C.

These are provided on the 12C, however, because natural logarithms, base-e exponentials, and the related power function y^x [= e^(x ln y)] have a solid place in finance. A principal P, compounded at annual rate r for one year in n periods yields a final value F:

F = P*[1 + r/n]^n

As n gets ever-larger (infinite compounding),

F = P*e^r

11. Which model(s) provide a "modulo division" function?

Answer: The 16C.

It is called "RMD", and not "MOD" as on the other HP calculators.

12. Which model(s) allow "F" as a program label?

Answer: The 16C.

To provide its hexadecimal-representation capability, the letter "F" was required. So, F is also made available as a program label. The 16C has this in common with the Pioneer-series HP-20S. (Of course, "F" is also available as a label on HP's alphanumeric or quasi-alphanumeric models.)

13. Which model(s) provide a y-estimator regression function?

Answer: The 10C and 12C.

Ironically, for all the other features these models lacked (see questions 3-6), only these Voyager models offered y-estimator!

This was probably due to lack of available keyboard space on the 11C and 15C, which also included regression-analysis functions.


Hope you enjoyed the quiz, but sorry -- no prize for a perfect score.

-- KS

Edited: 30 Aug 2005, 3:03 a.m. after one or more responses were posted


(I missed two...)

Thanks, Karl; I had my memory cells tested for sure.

I hope you are not mad because I actualy posted an answer right after you post the quiz; somehow a lucky moment of mine.

I'd add that the HP16C is actually the only Voyager that shows labels from [A] to [E] (plus [F]) as alphabetic characters. The HP11C and HP15C use [11] to [15], instead. BTW, this is something I accepted with some reluctance because the HP15C has the matrix identifiers A to E, so it could show these labels as well. Anyway, if we consider the many resources the HP15C has that are completely equivalent to the ones found in the HP11C, leaving [11] to [15] as identifiers for labels [A] to [E] would help understanding programs in one or in the other without much confusion.

Best regards.

Luiz (Brazil)

Edited: 30 Aug 2005, 2:43 a.m.


Luiz --

Thanks for your helpful replies. No, I'm not displeased at all that a quick response was posted. You might have prevented me from making a mistake, because I forgot that the 12C had y-estimator.

I also noticed that the 16C used A-F as keycodes, but those legends are on the keys, like 0-9.

In a way, I wish that the 15C did the same. It would make more sense for progam labels and matrices, but might be a bit confusing for the mathematical functions on keys 11-15, and for USER mode. There were also the issues of changing tried-and-true derivative 11C code and the limited ROM space.

It may seem kinda silly to be contemplate the quirks of a 23-year-old product, but it is an enlightening exercise to revisit the thinking of the first-class engineers who designed it.

-- KS


Hey, Karl;

you see, after 23 years we have still been surprised with the features of these little beasts. God bless the first-class engineers who worked on their design, development and production line. Amen!

I still feel compelled to comment these four HP11C not-programmable, yet valid entries, keystroke sequences. This is, as far as I know, the only case in all voyagers. If you try entering any of these as a program line, you'll always get [f][SCI]7 or [f][ENG]7. And there is no error message, neither [f][SCI][8], [f][SCI]9, [f][ENG]8 nor [f][ENG]9 can be coded as program lines in the HP11C. The HP10C accepts them, the HP15C accepts them, the HP11C doesn't. I guess that if we count all programmable keystroke conbinations plus these four ones in the HP11C repertoire, we'll reach 259 instead of 255. Anyway, if we consider the rounding factor, what if there is actualy no [f][SCI][8], [f][SCI]9, [f][ENG]8 nor [f][ENG]9 internally defined in the HP11C? Who can tell, except anyone from the project team? I mean, has anyone tested if there is any visible change in the display if we set [f][SCI][8] or [f][SCI]9 insstead of [f][SCI]7? Or if we set [f][ENG]8 or [f][ENG]9 instead of [f][ENG]7?

Maybe it also has to do with the limited ROM space... Or maybe this is old issue and I'm just talking about yesterday's news.


Luiz (Brazil)

Edited: 30 Aug 2005, 6:04 a.m.


... interesting tidbit, Luiz!

The 11C apparently converts a requested 8 or 9 significant digits to 7 in [SCI] and [ENG] because that's all the Voyager display can handle. The 10C and 15C just accept the overambitious demand, but display only what is possible.

There apparently is no difference in how, e.g., "SCI 8" and "SCI 7" appear. Checking and changing the precision does add a bit of ROM code, which was an issue in the development of the 15C.

I believe that much of the HP-34C's ROM was used in the 11C. It turns out, in fact, that the 34C also changes "ENG 8" to "ENG 7", as well as the other three cases.

The 34C and the 11C share virtually the same storage setup for programming and numbered registers, the same automatic memory allocation, the same 8 conditional tests, the same programming paradigm, and other things. Since the 56-bit BCD number precision is identical, the mathematical algorithms are also probably the same ones.

The small quirk that Luiz pointed out is further indication of the product development strategies that were undertaken 25 years ago.

-- KS

Edited: 31 Aug 2005, 2:24 a.m.


Hey, Karl; I, again!

One small spot: the RAN# 'register' in the HP11C. Is it actually a register? If we go ahead and actually count, the permanent program steps in the HP11C are counted 63 only and go to a maximun of 203, against the 70 permanent stpes in a maximun of 210 available in the HP34. So, it seems that the RAN# uses these borrowed seven bytes to exist, what actually cause both calculators to precisely match the amount of available memory each one has when compared to the other.

I also remember that Valentin once brought to us a short and sweet quiz where a number could be stored in the HP15C and retrieved to its mantissa x 10^(-1). The HP15C not only allows [STO][RAN#] as a valid programmable keystroke sequence, it goes further and accepts [RCL][RAN#], too (they are coded as [STO][ENTER] and [RCL][ENTER], being the [f] prefix ommited). The HP11C accepts [STO][RAN#] as a valid instruction, but it does not allow [RAN#] contents to be retrieved. So, anytime you need a random number, you must generate a new one in the HP11C, you cannot recall the last one unless you store it somewhere else. The HP15C allows such retrieval, but it cuts out the exponent of ten.

As you said:

(...)further indication of the product development strategies that were undertaken 25 years ago.


Luiz (Brazil)

Edited: 31 Aug 2005, 3:25 a.m.


The 34C uses the Woodstock CPU architecture (but not an actual ACT chip). The CPU contains the A, B, and C working registers, of which A and B together form the user X stack register. The CPU also contains the Y, Z, and T registers of the stack, and two temporary registers called M and N (or M1 and M2). The 34C has 64 RAM locations. The solve and integrate functions use dedicated RAM that is not available for other uses.

The 41C, 11C and 15C use the Nut processor. It has the A, B, and C registers, and M and N, but does not contain the stack, so the stack is stored in the "status registers" (RAM external to the processor).

The 11C contains one R2D2 chip (ROM/RAM/Display Driver), which provides eight storage registers (intended for use as "status registers" as in the 41C), two bitmapped display registers, one hardware control register (possibly a timer), and 32 general registers. Thus there are a total of 40 registers available outside
the CPU. The "status registers" include the stack, program pointer, partition pointer, return stack, flags, random number, etc.

The 15C contains two R2D2 chips, but in the second chip the display driver is not used, so the two display bitmap registers are available for general-purpose use. Thus the 15C has 18 "status registers" and 64 general registers. The status registers are used for basically the same purposes as in the 11C, and additionally for pointers and dimensions for the matrices, and pointers to the solve, integrate, and imaginary stack registers. Unlike the 34C, in the 15C solve and integrate do not have dedicated registers, but instead allocate registers out of the "free pool" between the user program and data registers.

The arithmetic, logarithmic, exponential, and trigonometric functions of the Spice series, 41C, and Voyager series are nearly identical. The Nut CPU introduced a few new instructions that could be used to optimize the math routines slightly. The 41C ROM source code (VASM listings) point out some of the places that optimizations could be made, but generally the optimizations were not actually used. In the Voyagers most of those optimizations were put into practice. However, I don't think there was any significant reduction in execution cycles as a result. Note that the Voyagers use a lower clock frequency than the 41C, so in generally they are significantly slower.



Thank you, Eric, for the insights.

The 41C, 11C and 15C use the Nut processor.

Note that the Voyagers use a lower clock frequency than the 41C, so in generally they are significantly slower.

I've often wondered whether HP deliberately "de-clocked" the Voyagers so that they did not outshine their flagship 41C. I've noticed that the 41's are about twice as fast as Voyagers. If expandability, I/O, advanced RPN programming, and time functions are not of concern, the 15C is arguably a far superior calc to any 41, and much less expensive. If only it were at least as fast...

Your link to a short article (which I had actually read before) provided more clues:

11C/15C speedup

-- KS


I've often wondered whether HP deliberately "de-clocked" the Voyagers so that they did not outshine their flagship 41C.

No. The 41C contains a switching power supply so that the voltage to the digital chips is constant even though the battery voltage declines. The Voyagers don't have a switching power supply; they operate directly on the three cells that may be as low as 1V each near end of life. Because of the lower supply voltage, the CMOS chips can't run as fast.


Indeed, a concise, complete, helpful set of compiled information about the Voyager series.

Thanks, Eric. This is not the kind of information easily found anywhere.

Luiz (Brazil)


Hi Luiz,

what if there is actualy no [f][SCI][8], [f][SCI]9, [f][ENG]8 nor [f][ENG]9 internally defined in the HP11C? Who can tell, except anyone from the project team? I mean, has anyone tested if there is any visible change in the display if we set [f][SCI][8] or [f][SCI]9 insstead of [f][SCI]7?

There is at least one usage of the SCI 8 setting: to round the mantissa to 9 digits with SCI 8 RND. This actually works from the keyboard. It can be used to get rid of the 10th digit during calculations to simulate a kind of guard digit.

I guess that if we count all programmable keystroke conbinations plus these four ones in the HP11C repertoire, we'll reach 259 instead of 255

I counted 254 programmable keystroke combinations for the HP-11C, so your hypothesis may be right. Maybe missed I one combination? Anyhow, there was no room for synthetic programming...




Jean François Garnier posted:

"I counted 254 programmable keystroke combinations for the HP-11C, so your hypothesis may be right."

Same for the HP-34C, it also had 254 programmable keystroke combinations, but you could also enter the one unused keycode
('poor man's synthetic programming') in a number of ways.

It's quite remarkable that the HP-15C, in the very same form factor
and external appearance as the HP-11C, does in fact manage to
cater for more than twice as many (700+) programmable keystroke
combinations, i.e., programmable operations. People not acquainted with both models would likely think they would be more similar.

Best regards from V.


i thought the 15c was an 8 bit machine too. did it get over the 256 limit by using multibyte instructions like the 41c?


Hi, Bubba;

yes, the HP15C has a set of many 2-byte instructions. As it has no ALPHA capabilities, it would be enough to add many 2-byte instructions in order to access its new, powerfull resources. I am not sure about which ones are the two-byte instructions, but I remember that most of them seem to be chosen because are not too much used as program lines. If I'm home later and no one else posts about it, I'll add a list of the 2-byte programmable instructions available in the HP15C repertoire.


Luiz (Brazil)

Edited: 1 Sept 2005, 3:07 p.m.


Hi, all;

this is the main set of 2-byte instructions in the HP15C's repertoire (from the "HP15C Owner's Handbook", Appendix C):

[f][LBL]. (0 to 9)            [f][MATRIX] (0 to 9)
[GTO]. (0 to 9) [f][x<>] (2 to 9, .0 TO .9)
[g][CF] (0 to 9, I) [f][DSE] (2 to 9, .0 TO .9)
[g][SF] (0 to 9, I) [f][ISG] (2 to 9, .0 TO .9)
[g][F?] (0 to 9, I) [STO]([+], [-], [×], [÷])
[f][FIX](0 to 9, I) [RCL]([+], [-], [×], [÷])
[f][SCI](0 to 9, I) [STO][MATRIX]([A] to [E])
[f][ENG](0 to 9, I) [STO]([A] to [E], (i)) in USER mode
[f][SOLVE] [RCL]([A] to [E], (i)) in USER mode
[f][integral] [STO][g](i) [RCL][g](i)
I hope this gives you extra info.


Luiz (Brazil)


There are 255; did you count "STO RAN#"?

Here's the
HP-11C Hex Table.

By comparison, the HP-16C Hex Table has thirteen spare codes. The 12C uses all 256 codes, but I don't yet have the hex table online. I haven't yet investigated the 10C and 11C.

The techniques for mapping the hex tables are left as an exercise for the reader. :-)


Those tables are fascinating Eric. I've thought about the internal representation of the 16C a *lot*. The comments/questions that follows may not apply to other Voyagers (but I don't see why not).

Consider the implementation of the set/clear/test bit functions which take the bit position parameter from the stack. Contrast this with the flag set/clear/test functions in which the flag number is implied by the low-order nybble of the opcode.

Since these two groups of functions could have been implemented in a substantially similar manner and since the bit functions are programmatically more flexible why were the flags implemented as they are?

On more than one occasion I've mapped the flags to bits and back to open up the range of logical operations (typically for branch determination). This chews up valuable keystrokes and (with the benefit of hindsight) the trade-off was seldom worth it. However had the flags (on all models) been like the bit functions the conversion overhead would never have been incurred.

As illustration, consider:

; if F0 AND F1 then do something else return
F? 0
GTO f0_is_set
LBL f0_is_set
F? 1
GTO do_something
LBL do_something

Contrasted with

; if F0 AND F1 then do something else return
RCL flags_stored_in_a_register

The latter saves three keystrokes (about 1.5% of total) and three labels (18.75% of total). The conservation of labels sometimes made this approach worth the effort.

One drawback of the flags-as-register approach is the stack management overhead which is not possible to illustrate in a trivial example. I concede that you also lose the keystroke
storage that holds the flags in "user space" but had the architecture allowed this approach to the flags that storage would have been in "system space".

Now that I've posed a few (hopefully interesting) questions, what do all of you think?


PS: which method of flag manipulation do the RPL calculators support?


Hi, Cameron;

I think something like this could do the job:

F? 0
F? 1
stuff if flags 0 and 1 are set
No labels, no registers. The price: stack registers contents. One thing I do not like in this approach is that only x-register contents is known after these program steps are executed: x-register = 1 if both flags are set, x-register = 0 if at least one of them is cleared.

PS: which method of flag manipulation do the RPL calculators support?
As for UserRPL manipulations, flags can be handled as a set, as separated memory space. You can retrieve flags status to stack level 1 by evaluating [RCLF], almost the same way it was done with the 41C/CV with X-functions, or an HP41CX, by using [RCLFLAG]. The main difference is that [RCLF] returns a list with two binary numbers: one reflecting system flags status, and another reflecting user flags status. Major problem is that extra manipulation must be performed to have access to any of them in this approach. But if you need to know flag status, like flags 1 and 2 (no flag numbered as '0' in RPL-based calculators), and want to handle their state, I think it's easier because RPL tests return flag status as 1 (true) or 0 (false) to the stack.
IF 1 FS? 2 FS? AND
THEN stuff if both flags are set
IF 1 FS? 2 FS? AND
THEN stuff if both flags are set
ELSE stuff if at least one of them is cleared
I like programming in RPL because of many reasons, and as I prefer using stack registers instead of regular memory registers (as long as it does no sacrifice performance neither stretches program lenght), RPL stack allows some maneuvers like handling flags status without loosing current contents. In the examples above, each FS? instruction removes the flag identificator and returns its status as 1 or 0. So, the AND operation will always find at least two arguments to combine and leave the result in stack level 1. Hence, the IF...THEN...(ELSE...)END structure removes the combined flag status left in stack level 1, and whatever existed in the remaining stack levels is left untouched. Based on these facts, the IF...THEN...(ELSE...)END structure needs something in stack level 1 prior to decide for THEN and opetionaly for ESLSE, so the flag manipulation may happen prior tho the structure itself. Like this:
1 FS? 2 FS? AND
THEN stuff if both flags are set
1 FS? 2 FS? AND
THEN stuff if both flags are set
ELSE stuff if at least one of them is cleared
This is something I like very much in RPL programming: you actually must keep track of what you leave in the stack registers. Trash must be removed, otherwise it will be left in the stack and if you have cyclic operations leaving trash, the stack may grow too fast and a Low Memory warnning is most likely to appear...

Hope this gives you a glimpse of what can be done.


Luiz (Brazil)

(BTW, Cameron, I think I lost the e-address to your HP16C page; would you post it, please?)

Edited: 2 Sept 2005, 12:18 p.m.


My web site now also has the HP-38C Hex Table and the HP-12C Hex Table. Neither have any spare codes.

Before I compiled these, I wasn't aware that the HP-38C had storage arithmetic on R0 through R6, but the HP-12C only has storage arithmetic on R0 through R4. That allowed HP to add eight more programmable functions to the 12C:

  • Depreciation: SL, SOYD, DB
  • Bonds: PRICE, YTM
  • BEGIN, END (was slide switch on 38C)
  • RCL g R/S

Edited: 2 Sept 2005, 2:05 a.m. after one or more responses were posted


Hi, Eric;

[RCL][PSE] is the instruction that forces the IRR calculation to go beyong the Error 3 warnning (multiple roots). It is explained in Appendix B, under 'More about IRR'. In the HP12C Owner's Handbook, [RCL][PSE] is coded as [RCL][g][R/S], and I think this is just a strategic way of calling the operation.

Either if invoked through the keyboard or through a program instruction, [RCL][PSE] takes x-register contents as a guess for [IRR] and tries to find an answer close to this guess. Once, some(how long) time ago, I wanted to investigate this particular case. I simulated a cash flow with a peculiar arrangement and by simply pressing [IRR] the calculator returned Error 3. I forced a wrong guess, too far from the possible answer, pressed [RCL][g][R/S] ([RCL][PSE]) and no Error 3 warnning occur, neither Error 7. The HP12C [IRR] routine ran for about an hour and I decided to stop the search with [R/S].

Just for the records...


Luiz (Brazil)

Edited: 2 Sept 2005, 1:49 a.m.


OK, I edited my posting and the hex table web page and the list to use HP's "RCL g R/S" designation rather then "RCL PSE". Either way it seems like a pretty obscure sequence. "STO g R/S" would have made slightly more sense to me, i.e., "store a new guess and continue the IRR calculation".

I'm still not completely convinced that it would be useful in a program.


Hi, Eric:

Eric posted:

"... to use RCL g R/S" designation rather then "RCL PSE". Either way it seems like a pretty obscure sequence. [...] I'm still not completely convinced that it would be useful in a program."

You can find a very useful (if unexpected) use of RCL g R/S as a program line in the HP-12C program featured in
this article of mine (see line 22).

Best regards from V.


There are 255; did you count "STO RAN#"?

The one I forgot was RCL Sigma+.

Thanks again, Eric, for sharing all these valuable informations!



A principal P, compounded at annual rate r for one year in n periods yields a final value F:
F = P*[1 + r/n]^n

Hi Karl,

Congratulations for this exhausted explanations.

A very quick comment on your formula. Yours is correct if the rate r is the american APR. But it is mathematically approximate.

If the period in n is not the same of the period of the rate (which is in most cases true, typically rate being annual and payment monthly), you need to convert the monthly rate to get the "true" annual rate, which turns out to be higher than expected.

For example, a 6% APR gives a .5% monthly rate. Compund the latter and you'll see that your rate is not 6% but 6.17%

In other words, unless we are talking about an APR and monthly payments, where n is always 12, the rate should not be divided by the number of periods (m) in the rate but "anti-coumpunded" by the formula ((1+i)^(1/m)-1).


Thibault --

There may be differences in convention for reporting interest rates, but it's not really that complicated:

A principal P, compounded at annual rate r for one year in n periods yields a final value F:

F = P*[1 + r/n]^n

As n gets ever-larger (infinite compounding),

F = P*e^r

The "annual rate r" is indeed intended as the simple-interest, uncompounded Annual Percentage Rate (APR), but it doesn't have to be annual -- it can be for any period of time. "n" is the number of equal-length compounding periods.

The equation simply illustrates that

 lim    [1 + r/n]^n  =  e^r

showing the use for ex, ln, and yx in a financial calculator.

Your example is correct: [1 + 0.06/12]12 = 1.06168; a 6% simple-interest rate becomes a 6.17% "effective" interest rate, in our parlance.

-- KS

Edited: 30 Aug 2005, 11:01 p.m.



Your approximation is very interesting. It reminded me of a method I devised in the late 70s to calculate e^x on requglar calculators using:

e^x = (1 + x / 2048)^2048

1) Divide x by 2048
2) Add 1
3) Square the result 11 times (press the sequence [x][=] 11 times)
4) You get e^x to a good approximation

Likewise you can calculate ln(x) using a calculator with a square root function:

ln(x) = 2048 * [x^(1/2048) - 1]

1) Take 11 successive square roots of x
2) Subtract 1
3) Multiply by 2048
4) You get an approximation of ln(x)

This approximation allowed a calculator with a square root to approximate ln(x). Sotring 2038 in a memory reguster helps some.


Thanks Karl.

I'm not an engineer nor a mathematician, but I've had the opportunity of learning all these financial concepts (and a few others more), and be reassured, I'm (hopefully) aware of all you're writing.

This is all a parlance issue. I just wanted to emphasize that the formula you used is appropriate in US mortgage calculation, but not in other countries. For example, Canadian mortgages are compounded semi-annually. In Europe, we use the effective rate.

And last but not least, I also wanted to demonstrate that one should be careful when taking in consideration an APR : the effective rate is always higher.


Interesting thread (I have a layman's interest in maths agorithms).

Karl, your comments reminded me of a calculator I begged my father to buy me in 1973 when I was ten. It was a SHEEN, with very limited
functions (sixteen keys on the keybaord).

The "interesting feature" was an unusual
implementation of a constant memory SHEEN called a RAM (! ;-).

The ram key (in the display filter-!) enabled you to add and multply, etc. using the constant so stored. Big deal...?!

BUT (<-- big "but")... the manual (yes it had one) had a really
interesting little chapter on higher mathematical functions you
could manually do by (very) creative use of the four function
constant memory. There were (paper) algorithms for square root,
using Newtons Method of iterative approximation, calculation of
"e" and a few other things I've forgotten. I THINK you could do
basic trigs (man, that was involved...)

Very off-topic but I thought I would share this little oddity...

Don W

Possibly Related Threads...
Thread Author Replies Views Last Post
  Micro Voyagers Matt Agajanian 11 2,293 08-26-2013, 05:11 PM
Last Post: Stephan Matthys
  Voyagers width Gerson W. Barbosa 11 2,300 12-18-2012, 07:52 PM
Last Post: Gerson W. Barbosa
  HP-41 Quiz: How to pack 100k in ROM? (on-line) Ángel Martin 10 2,188 09-02-2012, 10:35 PM
Last Post: Luiz C. Vieira (Brazil)
  A visual quiz! What is it? Geoff Quickfall 5 1,361 04-04-2009, 05:45 AM
Last Post: Maximilian Hohmann
  How do I glue the back label of an HP-16C back on? (or of most Voyagers, for that matter) Philippe Lasnier 4 1,088 02-22-2009, 12:59 PM
Last Post: Philippe Lasnier
  Black Box Answers Hal Bitton in Boise 1 626 08-11-2008, 08:17 AM
Last Post: Maximilian Hohmann
  Damn....I really like the Voyagers Jimi 4 1,198 07-15-2008, 03:39 AM
Last Post: MikeO
  Trivia quiz and mini-challenge: Classic HP35 Allen 25 4,074 10-08-2007, 06:00 PM
Last Post: Paul Dale
  Trade Answers for HP71B case Recomendation RonHudson(USA) 7 1,449 09-05-2007, 12:57 PM
Last Post: Garth Wilson
  My Hp 50g is giving answers in fractions!! PhysicsNerd 10 2,014 05-14-2007, 01:55 AM
Last Post: martin

Forum Jump: