Someone mentioned that their HP15C circa 1985 took 30 seconds to compute 69 factorial. My vintage HP15C computes that almost instantaneously. I purchased mine in 1990, and going by the serial number, it was built in 1986 (first 2 digits are 26 which indicate the number of years since 1960). I'm considering purchasing one from 1983 or 1984, so if those are significantly slower, I'd really like to know that before I buy it.

I'd appreciate it if someone with an older model can tell me how fast their calculators perform the following 2 functions:

69 f x!

100 ENTER 50 g Cx,y

The second of those takes much longer than the first - about 10 seconds on mine.

Please post the first 4 digits of the serial number with any results. I'm only talking about the vintage models here. I understand that the new limited editions are much faster.

Thanks.

Quote:

---

Someone mentioned that their HP15C circa 1985 took 30 seconds to compute 69 factorial.

---

They may have just been mistaken. The clock frequency
hasn't seen a manufacturing change and I've never come across
more that one version of hp released firmware for the 15c.

Quote:

---

I'd appreciate it if someone with an older model can tell me how fast their calculators perform the following 2 functions:

69 f x!

100 ENTER 50 g Cx,y

The second of those takes much longer than the first - about 10 seconds on mine.

Please post the first 4 digits of the serial number with any results. I'm only talking about the vintage models here. I understand that the new limited editions are much faster.

---

~10s for x! and 0.5s for Cx,y on a 24xx and 25xx 15c.

69! is quick.

100C50 takes 11.3 s on my 24xxA and 11.6 s on my 27xxA.

Quote:

---

Please post the first 4 digits of the serial number with any results.

---

This is irrelevant. Any differences you may notice are due to modifications done by some users, they are not related to the serial numbers. Please take a look at the following past threads:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv015.cgi?read=77430

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv019.cgi?read=157905 (professionally done mod)

Regards,

Gerson.

-------------------

Since you've asked:

69 f x! -> about 0.8 seconds

100 ENTER 50 g Cx,y -> 11.4 seconds

69.5 CHS f x! -> 13.5 seconds.

(2343B75099, no mod)

Edited: 26 Jan 2012, 2:19 a.m.

Bruce wrote:

Quote:

---

Someone mentioned that their HP15C circa 1985 took 30 seconds to compute 69 factorial.

---

Quote:

---

My vintage HP15C computes that almost instantaneously.

---

Quote:

---

I'd appreciate it if someone with an older model can tell me how fast their calculators perform the following 2 functions:
 
69 f x!
 
100 ENTER 50 g Cx,y
 
The second of those takes much longer than the first - about 10 seconds on mine.

---

Anyway, I wonder why the 15C took that long for the Cx,y function which is essentially a loop with 50 multiplications and divisions. The current 35s does this within a second, and even a hand-written program in user code does it in just 5 seconds. Yes, the 35s is much faster faster than the 15C (ten, maybe twenty times), but shouldn't a 15C-routine in machine code run at least as fast as a 35s-program in user code?!

Dieter

Edited: 26 Jan 2012, 7:20 a.m.

Dieter are you sure the 15C uses multiplications for Cxy? Another approach could be using lnGamma.

Quote:

---

Anyway, I wonder why the 15C took that long for the Cx,y function which is essentially a loop with 50 multiplications and divisions. The current 35s does this within a second, and even a hand-written program in user code does it in just 5 seconds. Yes, the 35s is much faster faster than the 15C (ten, maybe twenty times), but shouldn't a 15C-routine in machine code run at least as fast as a 35s-program in user code?!

---

I'm guessing that it takes precautions against overflow such as adding logs. Something like that is required for larger combinatorics.

I don't think that the 15C uses logs for the C(y,x) function. The usual straightforward implementation of this function will not cause an overflow either - at long as the result doesn't overflow as well.

Example for C(400, 108) = 9,432 E+99:

C(400, 108)  =  400 / 108 * 399 / 107 * 398 / 106 * ... * 294 / 2 * 293 / 1

Dieter

Of course I'm not sure of anything as far as the internal programming of the 15C is concerned. But I don't think that a lngamma approach is used here. First, because in this case that function probably would have been made available to the user. And second, simply think of the time three lngammas would require here... #-)

Dieter

Quote:

---

I don't think that the 15C uses logs for the C(y,x) function. The usual straightforward implementation of this function will not cause an overflow either - at long as the result doesn't overflow as well.

Example for C(400, 108) = 9,432 E+99:

C(400, 108)  =  400 / 108 * 399 / 107 * 398 / 106 * ... * 294 / 2 * 293 / 1

Before the last multiplication the value is less than the final result, which is then obtained by the multiplication with 293. In other words: there is no "intermediate overflow". As long as the result is within the limits, the algorithm will not cause an overflow either. At least that's what it looks to me. ;-)

---

You're right, I was thinking of evaluating the binomial distribution, where the C(y,x) terms can overflow even though the binomial terms do not since the large C(y,x) terms get multiplied by very small values. Excel had a problem with this a few years ago, and they implemented an algorithm to fix it. That can also be fixed by summing logs. Of course the HP15C doesn't have a key for the binomial distribution.

Quote:

---

Of course I'm not sure of anything as far as the internal programming of the 15C is concerned. But I don't think that a lngamma approach is used here. First, because in this case that function probably would have been made available to the user.

---

The x! key appears to return gamma(x+1). For example, -0.5! returns gamma(0.5) = sqrt(pi).

Regarding statistical functions I don't think Excel has problems. For me it looks more like Excel is the problem. ;-)

Just as C(y,x), also the binomial pdf can be evaluated with minimal overflow risk. For instance this way (just the basic idea):

function binpdf(x, n, p)

  q = 1-p

  poverq = p/q

  pdf = q^n

  for k = 1 to x

      pdf = pdf * (n - k + 1) / k * poverq

  next k

  binpdf = pdf

end function

Dieter

Quote:

---

The x! key appears to return gamma(x+1). For example, -0.5! returns gamma(0.5) = sqrt(pi).

---

However, obviously two different algorithms are used for the factorial and the gamma function. Try 10! and the result appears immediately, as with other non-negative integers. Then try 10.001! and the calculator has to switch to "gamma mode" where the result requires a few seconds of computation time.

Dieter

Quote:

---

Regarding statistical functions I don't think Excel has problems. For me it looks more like Excel is the problem. ;-)

Just as C(y,x), also the binomial pdf can be evaluated with minimal overflow risk. For instance this way (just the basic idea):

function binpdf(x, n, p)

  q = 1-p

  poverq = p/q

  pdf = q^n

  for k = 1 to x

      pdf = pdf * (n - k + 1) / k * poverq

  next k

  binpdf = pdf

end function

The major risk here is an underflow during the calculation of q^n. ;-)

---

Here is a link about Microsoft's fix (near the bottom).

Quote:

---

..I've never come across more that one version of hp released firmware for the 15c.

---

But I have come across an apparent oddity which may relate
to a firmware version change.

I had loan of a 10c for the purpose of testing KEMU with
that model's firmware. When the 10c was running I would
get jibberish on the display but the system test would
succeed and render all available segments. It took me
a while to realize the display mapping was different than
every other voyager I've encountered.

This was a 22xx serial number 10c which has the early
satellite PCB containing the NUT and display controller.
However I have 23xx voyagers with the same satellite
PCB configuration, and firmware captured from them treats
the display mapping identical to the later single PCB voyagers.
So I'm unsure whether the display mapping difference here
is a function of the 10c, s/n <= 22xx voyagers, or possibly both.

The sequence of segments enabled during the keypad test for
both cases differs although the data written to the display
registers is identical. This makes for a simple check to
determine what units have this configuration, just by the first
set of segments enabled when the keypad ON + <div> test is
selected. The corresponding sequences are
here although the first display rendered in the
sequence is all which is needed. I've only ever encountered
the "A" version up until the "B" version generated by this 10c.

Would someone with a 22xx serial number voyager other than a
10c mind telling me what sequence is followed? Also if
someone has access to a 22xx < s/n 10c I'd be interested to
know how that behaves as well.

Thanks!

Interesting find and nice display pattern map!

My collection verifies what you said:

10C 22xx --> b

10C 23xx --> b

11C 20xx --> a

11C 26xx --> a

12C 25xx --> a

12C 33xx --> a

15C 25xx --> a

16C 22xx --> a

16C 25xx --> a

Edited: 4 Feb 2012, 11:34 a.m.

Quote:

---

Interesting find and nice display pattern map!

My collection verifies what you said:

10C 22xx --> b

10C 23xx --> b

11C 20xx --> a

---

Hmm.. given the above this may be a quirk unique to the 10c.

I have a 2301A 16c and several 23xxA 12c units which all possess
the 'a' behaviour. I suppose the only missing data point
would be a 24xx 10c, but I wouldn't expect a surprise there.
AFAIK that was the last production year for the 10c.

It looks to be a layout change for unknown reasons on the
display flex pcb. It is possible the R2D2 in the 10c has
a modified pinout which admittedly makes little sense. The ROM
image is only 4K words vs. 6K for other voyager models
but I haven't tried to drive the bus to determine whether
it appears the upper 2K is unused or simply not present.
Nothing above 4K is accessed when the image is executing in
KEMU and the self test checksum only addresses that range.
The device code is 1LF7-0301 which I've never encountered
before, however I'd expect an actual silicon change outside of
the rom mask to be unlikely.

Unknown at this point. If I ever manage to add a 10c to my
own collection I'll trace out the display pcb when I run out
of things to do. ;)

Thanks!

[edit: fix formatting botch]

Edited: 4 Feb 2012, 4:14 p.m.