Simulating 15C RAN # on 35s - Printable Version +- 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: Simulating 15C RAN # on 35s ( /thread-3088.html) |

Simulating 15C RAN # on 35s - Tugdual - 02-14-2015 05:13 PM
This 35s program will return the exact same RAN # values as the 15C (Don't even ask me why I did that...). Fun fact: the seed 0.8603685347 returns zero Algo: RND(n+1) = Frac(1574352261*RND(n) + 0.1017980433) The challenge is to compute this with only 14 digits on the mantisse. On the 34s with D mode, you get instantly the result :-). Usage: Enter a SEED and then XEQ A Press R/S for next RAN# values Notes: IP is obtained with Left shift INTG 6 FP is obtained with Left shift INTG 5 Code: `A001 LBL A` RE: Simulating 15C RAN # on 35s - Namir - 02-15-2015 03:44 AM
The expression: Frac(1574352261*0.8603685347) Yields zero. However, adding 0.1017980433 to it returns 0.1017980433!! Namir RE: Simulating 15C RAN # on 35s - Tugdual - 02-15-2015 04:01 AM
Hi Namir , you'll need a 34s with double precision to do the calculation since you need 20 digits (or so). The 35s code is looping on each digit to allow the calculation on 12 digits. Frac(1574352261*0.8603685347) = 0.8982019567 Adding 0.1017980433 returns exactly 1. Since IP is systematically dropped, this is equivalent to zero. RE: Simulating 15C RAN # on 35s - Paul Dale - 02-15-2015 05:24 AM
Shouldn't there be a FRAC surround the entire expression? Regardless of the need for the FRAC around the multiplication. - Pauli RE: Simulating 15C RAN # on 35s - Thomas Klemm - 02-15-2015 07:28 AM
(02-15-2015 05:24 AM)Paul Dale Wrote: Shouldn't there be a FRAC surround the entire expression? Correct: RND(n+1) = Frac(1574352261*RND(n) + 0.1017980433) Or then we could use: RND(n+1) = Frac(15743.52261*(\(10^5\)*RND(n)) + 0.1017980433) This allows to split the factors into an integer and fraction part and use: \((a+b)(c+d)=ac+ad+bc+bd\) The good thing is that \(ac\) is an integer. Thus we can omit it. Here's a program for the HP-42S: Code: `00 { 56-Byte Prgm }` It should be straightforward to translate that to the HP-35S. Cheers Thomas RE: Simulating 15C RAN # on 35s - Tugdual - 02-15-2015 08:03 AM
@Pauli yes you are right, I fixed my 1st entry. @Thomas, very nice; not straightforward since "RCL* ST L" doesn't exist on the 35s. I like the optimization of stack usage to avoid intermediate variables and also no loop here! RE: Simulating 15C RAN # on 35s - Thomas Klemm - 02-15-2015 08:24 AM
(02-15-2015 08:03 AM)Tugdual Wrote: @Thomas, very nice; not straightforward since "RCL* ST L" doesn't exist on the 35s. Code: `R001 LBL R` Cheers Thomas RE: Simulating 15C RAN # on 35s - Tugdual - 02-15-2015 10:37 AM
Very nice, thanks Thomas. With the 35s full steam and your factor trick, I could achieve the same result with even fewer lines but I guess RPN purists will hate it :-) Code: `S001 LBL S ` RE: Simulating 15C RAN # on 35s - Paul Dale - 02-15-2015 11:21 AM
What about the checksum????? Pauli RE: Simulating 15C RAN # on 35s - Thomas Klemm - 02-15-2015 11:37 AM
(02-15-2015 10:37 AM)Tugdual Wrote: RPN purists will hate it As long as you're not concerned with performance I don't see a reason for not using it. But then it may become a nightmare to edit the equation. There's an older thread dealing with the RAN# function of the HP-15C that might interest you as well. Best regards Thomas RE: Simulating 15C RAN # on 35s - Tugdual - 02-15-2015 11:42 AM
(02-15-2015 11:21 AM)Paul Dale Wrote: What about the checksum?????Ha ha well, pick a value! Seriously LN is ok, it is the number of lines * 3 + number of characters in EQN and literals. But indeed it is a pretty weak control and the checksum... well you know about it. RE: Simulating 15C RAN # on 35s - Tugdual - 02-15-2015 12:01 PM
(02-15-2015 11:37 AM)Thomas Klemm Wrote: As long as you're not concerned with performance I don't see a reason for not using it. But then it may become a nightmare to edit the equation.It seems indeed natural to expect RPN to be faster but providing that literals are the same as EQN and the whole code is made of token I wonder how exactly faster RPN would be. I also wonder what the mechanic behind EQN is; it doesn't seem to rely on stack at all otherwise X would be altered during calculation in a totally unpredictable way. When you press MODE, ALG comes before RPN. Should we conclude that ALG is the preferred method and RPN would be somehow emulated? That could make sense since the processor is a generic 8502 and not a Saturn. Thanks for the link on HP15C RAN#, interesting reading. Note: regarding the question on performance I have redone the test http://www.thimet.de/CalcCollection/CalcPerformance.html with a modified 35s code Code: `A001 LBL A` I found 40s vs 36s. Slightly less performant... almost hard to conclude. RE: Simulating 15C RAN # on 35s - Thomas Klemm - 02-15-2015 12:54 PM
(02-15-2015 12:01 PM)Tugdual Wrote: I wonder how exactly faster RPN would be. The equation has to be parsed each time it's executed. You can even enter an expression that leads to a SYNTAX ERROR like: Code: `SQRT(` But unless the same equation is evaluated again and again in a loop as in SOLVE or \(\int\) you probably never notice the difference. Cheers Thomas RE: Simulating 15C RAN # on 35s - rprosperi - 02-15-2015 03:30 PM
(02-15-2015 07:28 AM)Thomas Klemm Wrote: Or then we could use: Thomas - Could you plz explain the transition splitting the factors to "(a+b)(c+d)"? I simply can't follow this. RE: Simulating 15C RAN # on 35s - Tugdual - 02-15-2015 03:45 PM
(02-15-2015 03:30 PM)rprosperi Wrote:This is what I understood:(02-15-2015 07:28 AM)Thomas Klemm Wrote: Or then we could use: If RND(n) = 0.aaaaabbbbb then \(10^5\)*RND(n) = aaaaa.bbbbb So this becomes (15743 + 0.52261) * (aaaaa + 0.bbbbb) aaaaa*15743 has no fractional part so you can drop it What Thomas didn't mention (but implied in his code) is that 0.52261 * 0.bbbbb < 1 so you don't need to FP this part but aaaaa * 0.52261 > 1 as well as 15743 * 0.bbbbb > 1 so you need to FP the sum of these two ones first otherwise you will end up with 10 digits in the mantissa of which 5 will be used for IP. RE: Simulating 15C RAN # on 35s - rprosperi - 02-15-2015 04:12 PM
(02-15-2015 03:45 PM)Tugdual Wrote: This is what I understood: Thank you Tugdual, very clear now. As we've come to expect from Thomas, very insightful and clever. Thanks to both of you! RE: Simulating 15C RAN # on 35s - Thomas Klemm - 02-15-2015 05:00 PM
(02-15-2015 04:12 PM)rprosperi Wrote: Thank you Tugdual, very clear now. Indeed, that's a very comprehensible explanation. Sorry for being sloppy sometimes but please never hesitate to ask if something is unclear. Best regards Thomas PS: Maybe it's worth noting that \(15743\times 0.bbbbb+0.52261\times aaaaa\) will use at most 11 digits. Thus we're fine with the 12 digits of the HP-35S or HP-42S and don't need to FP each of the products before adding them. This could lead to problems when using a calculator that provides only 10 digits as the HP-15C for example. RE: Simulating 15C RAN # on 35s - Tugdual - 02-15-2015 05:17 PM
(02-15-2015 05:00 PM)Thomas Klemm Wrote: PS: Maybe it's worth noting that \(15743\times 0.bbbbb+0.52261\times aaaaa\) will use at most 11 digits. Thus we're fine with the 12 digits of the HP-35S or HP-42S and don't need to FP each of the products before adding them. This could lead to problems when using a calculator that provides only 10 digits as the HP-15C for example.(15743 * 99999 + 52261 * 99999) * 1e-5 = 6 800 331 996 1e-5 This is 10 digits. How do you conclude 11 are necessary? Edit: hmmm ok I have a clue. 0.1017980433 is actually 11 digits... So I had to enter 1017980433 * 1e-10 and STO 0 to store the complete value (using PREFIX we see the 10 digits despite the starting 0). Unfortunately this doesn't work during calculations... RE: Simulating 15C RAN # on 35s - Thomas Klemm - 02-15-2015 05:57 PM
(02-15-2015 05:17 PM)Tugdual Wrote: How do you conclude 11 are necessary? Good catch! I assumed the general case where this can actually happen. But with only 10 digits we still have to avoid overflow when adding the numbers or we will lose the last digit. I just wanted to point out that you can't use this program unmodified with a HP-15C. Cheers Thomas |