Simulating 15C RAN # on 35s

02142015, 05:13 PM
(This post was last modified: 02152015 08:01 AM by Tugdual.)
Post: #1




Simulating 15C RAN # on 35s
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 

02152015, 03:44 AM
Post: #2




RE: Simulating 15C RAN # on 35s
The expression:
Frac(1574352261*0.8603685347) Yields zero. However, adding 0.1017980433 to it returns 0.1017980433!! Namir 

02152015, 04:01 AM
(This post was last modified: 02152015 04:01 AM by Tugdual.)
Post: #3




RE: Simulating 15C RAN # on 35s
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. 

02152015, 05:24 AM
Post: #4




RE: Simulating 15C RAN # on 35s
Shouldn't there be a FRAC surround the entire expression?
Regardless of the need for the FRAC around the multiplication.  Pauli 

02152015, 07:28 AM
Post: #5




RE: Simulating 15C RAN # on 35s
(02152015 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 HP42S: Code: 00 { 56Byte Prgm } It should be straightforward to translate that to the HP35S. Cheers Thomas 

02152015, 08:03 AM
(This post was last modified: 02152015 08:05 AM by Tugdual.)
Post: #6




RE: Simulating 15C RAN # on 35s
@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! 

02152015, 08:24 AM
Post: #7




RE: Simulating 15C RAN # on 35s
(02152015 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 

02152015, 10:37 AM
(This post was last modified: 02152015 10:38 AM by Tugdual.)
Post: #8




RE: Simulating 15C RAN # on 35s
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 

02152015, 11:21 AM
Post: #9




RE: Simulating 15C RAN # on 35s
What about the checksum?????
Pauli 

02152015, 11:37 AM
Post: #10




RE: Simulating 15C RAN # on 35s
(02152015 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 HP15C that might interest you as well. Best regards Thomas 

02152015, 11:42 AM
Post: #11




RE: Simulating 15C RAN # on 35s  
02152015, 12:01 PM
(This post was last modified: 02152015 12:44 PM by Tugdual.)
Post: #12




RE: Simulating 15C RAN # on 35s
(02152015 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/Calc...mance.html with a modified 35s code Code: A001 LBL A I found 40s vs 36s. Slightly less performant... almost hard to conclude. 

02152015, 12:54 PM
Post: #13




RE: Simulating 15C RAN # on 35s
(02152015 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 

02152015, 03:30 PM
Post: #14




RE: Simulating 15C RAN # on 35s
(02152015 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. Bob Prosperi 

02152015, 03:45 PM
(This post was last modified: 02152015 03:54 PM by Tugdual.)
Post: #15




RE: Simulating 15C RAN # on 35s
(02152015 03:30 PM)rprosperi Wrote:This is what I understood:(02152015 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. 

02152015, 04:12 PM
Post: #16




RE: Simulating 15C RAN # on 35s
(02152015 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! Bob Prosperi 

02152015, 05:00 PM
Post: #17




RE: Simulating 15C RAN # on 35s
(02152015 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 HP35S or HP42S 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 HP15C for example. 

02152015, 05:17 PM
(This post was last modified: 02152015 05:41 PM by Tugdual.)
Post: #18




RE: Simulating 15C RAN # on 35s
(02152015 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 HP35S or HP42S 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 HP15C for example.(15743 * 99999 + 52261 * 99999) * 1e5 = 6 800 331 996 1e5 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 * 1e10 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... 

02152015, 05:57 PM
Post: #19




RE: Simulating 15C RAN # on 35s
(02152015 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 HP15C. Cheers Thomas 

« Next Oldest  Next Newest »

User(s) browsing this thread: 2 Guest(s)