+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: An HP-35 (could be) workaround for ln 2.02 (/thread-22019.html)
An HP-35 (could be) workaround for ln 2.02 - Matt Agajanian - 07-10-2024 01:29 AM
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.
RE: An HP-35 (could be) workaround for ln 2.02 - teenix - 07-10-2024 04:52 AM
On my HP-35 red dot emulator, I get .7030975113 after the division
2.02 still shows up as the answer though
cheers
Tony
RE: An HP-35 (could be) workaround for ln 2.02 - dm319 - 07-11-2024 12:38 PM
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?
RE: An HP-35 (could be) workaround for ln 2.02 - bwiese - 07-12-2024 12:22 AM
(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
RE: An HP-35 (could be) workaround for ln 2.02 - Thomas Klemm - 07-12-2024 01:07 PM
(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 ex 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.
RE: An HP-35 (could be) workaround for ln 2.02 - AndiGer - 07-12-2024 02:53 PM
(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
RE: An HP-35 (could be) workaround for ln 2.02 - Thomas Klemm - 07-12-2024 03:21 PM
(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 -> pThus I assume that indeed \(\ln(10)\) is used to calculate the LOG function.