An HP-35 (could be) workaround for ln 2.02

[Matt Agajanian]

Hi all.

While fiddling around with RPN-35 set to Vintage Mode and HP-35 v1, it looks like to me, if Cuvee’s app accurately clones a Version 1 35, I think the following route could be useful.

Here it goes:

2.02 log
1 e^x log ÷

.7030975115 shows up

Then, while still in v1 Vintage mode
pressing e^x results in 2.02.

Oddly enough, I also went through the same steps using ln instead of log. It worked!

Even though it’s a few extra steps than the direct 2.02 ln, it looks to me a reasonable alternative. Besides, the 35 isn’t programmable, so we don’t need to worry about writing excessive program steps.

If RPN-35 is any indication, these steps should work on an actual version 1 HP-35 that has the bug.

You’re welcome.

And yeah. I know, this is probably yesterday’s news to members here.

[teenix]

On my HP-35 red dot emulator, I get .7030975113 after the division

2.02 still shows up as the answer though

cheers

Tony

[dm319]

That's interesting, I'd only heard about the bug in passing. So does this mean the log function doesn't use the code of the lnn function?

[bwiese]

(07-11-2024 12:38 PM)dm319 Wrote:  That's interesting, I'd only heard about the bug in passing. So does this mean the
log function doesn't use the code of the ln function?

May well use different constant tables instead of scaling by ln 10 (2.3025851...) or log 2 (.30103..)
-Bill

[Thomas Klemm]

(07-10-2024 01:29 AM)Matt Agajanian Wrote:  if Cuvee’s app accurately clones a Version 1 35

From RPN-35 SD — The first photo-realistic HP-35 simulator for the iPhone:

Quote:RPN-35 SD is a photo-realistic simulation of Hewlett-Packard's break-through scientific hand-held calculator.

I doubt it does.

(07-10-2024 01:29 AM)Matt Agajanian Wrote:  Here it goes:

2.02 log
1 e^x log ÷

.7030975115 shows up

(07-10-2024 04:52 AM)teenix Wrote:  On my HP-35 red dot emulator, I get .7030975113 after the division

Using this microcode-level emulation of the HP-35 running the original v2 ROM I get the same result:
.7030975113

As mentioned in 4.2) The so called “idiosyncrasy”:

Quote:The HP35 errata sheet says “The idiosyncrasy is in the e^x function, not in the logarithmic function.”

Apparently the buggy implementation is very sensitive to this value.
In both cases of the ROM (v2 and v4) the LN function of 2.02 returns the same value .7030975114.

However, in case of the buggy ROM v2 using .7030975114 instead of .7030975113 returns 2. instead of 2.02.
This was fixed in ROM v4.

[AndiGer]

(07-10-2024 04:52 AM)teenix Wrote:  On my HP-35 red dot emulator, I get .7030975113 after the division

2.02 still shows up as the answer though

cheers

Tony

Went to the real thing - HP-35 V2 with 2.02 bug.
2.02 ln --> .7030975114 --> e^x --> 2
2.02 log 1 e^x log ÷ --> .7030975113 --> e^x --> 2.02

Andi

[Thomas Klemm]

(07-12-2024 12:22 AM)bwiese Wrote:  May well use different constant tables instead of scaling by ln 10 (2.3025851...) or log 2 (.30103..)

I was running x11-calc-35 with the trace-option -t to calculate LOG 2.
Here's what I found:

Code:

0-1367 1414  12 -> p
0-1370 0230  load constant 2        reg['C'] = 0x02000000000000
0-1371 0330  load constant 3        reg['C'] = 0x02300000000000
0-1372 0030  load constant 0        reg['C'] = 0x02300000000000
0-1373 0230  load constant 2        reg['C'] = 0x02302000000000
0-1374 0530  load constant 5        reg['C'] = 0x02302500000000
0-1375 1007  if nc go to 1201
0-1201 1030  load constant 8        reg['C'] = 0x02302580000000
0-1202 0530  load constant 5        reg['C'] = 0x02302585000000
0-1203 0030  load constant 0        reg['C'] = 0x02302585000000
0-1204 1130  load constant 9        reg['C'] = 0x02302585090000
0-1205 1653  if nc go to 1352
0-1352 0330  load constant 3        reg['C'] = 0x02302585093000
0-1353 1567  if nc go to 1335
0-1335 1414  12 -> p

Thus I assume that indeed \(\ln(10)\) is used to calculate the LOG function.