An HP-35 (could be) workaround for ln 2.02
|
07-10-2024, 01:29 AM
(This post was last modified: 07-10-2024 01:33 AM by Matt Agajanian.)
Post: #1
|
|||
|
|||
An HP-35 (could be) workaround for ln 2.02
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. |
|||
07-10-2024, 04:52 AM
Post: #2
|
|||
|
|||
RE: An HP-35 (could be) workaround for ln 2.02
On my HP-35 red dot emulator, I get .7030975113 after the division
2.02 still shows up as the answer though cheers Tony |
|||
07-11-2024, 12:38 PM
Post: #3
|
|||
|
|||
RE: An HP-35 (could be) workaround for ln 2.02
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?
|
|||
07-12-2024, 12:22 AM
Post: #4
|
|||
|
|||
RE: An HP-35 (could be) workaround for ln 2.02 | |||
07-12-2024, 01:07 PM
Post: #5
|
|||
|
|||
RE: An HP-35 (could be) workaround for ln 2.02
(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: (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. |
|||
07-12-2024, 02:53 PM
Post: #6
|
|||
|
|||
RE: An HP-35 (could be) workaround for ln 2.02
(07-10-2024 04:52 AM)teenix Wrote: On my HP-35 red dot emulator, I get .7030975113 after the division 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 |
|||
07-12-2024, 03:21 PM
Post: #7
|
|||
|
|||
RE: An HP-35 (could be) workaround for ln 2.02
(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 Thus I assume that indeed \(\ln(10)\) is used to calculate the LOG function. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)