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 A002 STO A A003 SF 1 A004 10 A005 STO B A006 CLx A007 ENTER A008 1574352261 A009 RCL / B A010 STO C A011 FP A012 RCL A A013 RCL* B A014 ENTER A015 FP A016 STO A A017 x=0? A018 CF 1 A019 R↓ A020 IP A021 * A022 + A023 RCL C A024 FS? 1 A025 GTO A009 A026 R↓ A027 0.1017980433 A028 + A029 FP A030 RTN 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 } 01 LBL "RAN#" 02 1E5 03 * 04 FP 05 LASTX 06 IP 07 0.52261 08 * 09 X<>Y 10 RCL* ST L 11 LASTX 12 15743 13 * 14 R↑ 15 + 16 FP 17 + 18 0.1017980433 19 + 20 FP 21 END 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 R002 1E5 R003 × R004 FP R005 LASTx R006 IP R007 0.52261 R008 × R009 X<>Y R010 LASTx R011 X<>Y R012 × R013 LASTx R014 15743 R015 × R016 R↑ R017 + R018 FP R019 + R020 0.1017980433 R021 + R022 FP R023 RTN 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  S002 1E5 S003 x S004 FP S005 LASTx S006 IP S007 EQN FP(FP(15743*REGY+0.52261*REGX)+0.52261*REGY+0.1017980433) S008 RTN 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????? Pauli 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. There's an older thread dealing with the RAN# function of the HP-15C that might interest you as well. Best regards Thomas 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 A002 10 A003 STO A A004 (REGX+1-4.567E-4+70-69)*7/11 A005 RCL A A006 1 A007 - A008 STO A A009 x≠0? A010 GTO A004 A011 R↓ A012 SQRT(SQRT(SIN(LOG(REGX)))) A013 RTN 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( With the HP-48 this is not possible as the algebraic expression is parsed and stored in a compiled format. From this the algebraic expression is recreated for the display. That's why entering something like '(A+B)' with superfluous parentheses results just in 'A+B'. 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: 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. 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:   (02-15-2015 07:28 AM)Thomas Klemm Wrote:  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. Thomas - Could you plz explain the transition splitting the factors to "(a+b)(c+d)"? I simply can't follow this. This is what I understood: 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: 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. 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