Simulating 15C RAN # on 35s
02-14-2015, 05:13 PM (This post was last modified: 02-15-2015 08:01 AM by Tugdual.)
Post: #1
 Tugdual Senior Member Posts: 756 Joined: Dec 2013
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 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
02-15-2015, 03:44 AM
Post: #2
 Namir Senior Member Posts: 813 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
The expression:

Frac(1574352261*0.8603685347)

Yields zero. However, adding 0.1017980433 to it returns 0.1017980433!!

Namir
02-15-2015, 04:01 AM (This post was last modified: 02-15-2015 04:01 AM by Tugdual.)
Post: #3
 Tugdual Senior Member Posts: 756 Joined: Dec 2013
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.
02-15-2015, 05:24 AM
Post: #4
 Paul Dale Senior Member Posts: 1,733 Joined: Dec 2013
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
02-15-2015, 07:28 AM
Post: #5
 Thomas Klemm Senior Member Posts: 1,447 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
(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
02-15-2015, 08:03 AM (This post was last modified: 02-15-2015 08:05 AM by Tugdual.)
Post: #6
 Tugdual Senior Member Posts: 756 Joined: Dec 2013
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!
02-15-2015, 08:24 AM
Post: #7
 Thomas Klemm Senior Member Posts: 1,447 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
(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
02-15-2015, 10:37 AM (This post was last modified: 02-15-2015 10:38 AM by Tugdual.)
Post: #8
 Tugdual Senior Member Posts: 756 Joined: Dec 2013
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  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
02-15-2015, 11:21 AM
Post: #9
 Paul Dale Senior Member Posts: 1,733 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
What about the checksum?????

Pauli
02-15-2015, 11:37 AM
Post: #10
 Thomas Klemm Senior Member Posts: 1,447 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
(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
02-15-2015, 11:42 AM
Post: #11
 Tugdual Senior Member Posts: 756 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
(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.
02-15-2015, 12:01 PM (This post was last modified: 02-15-2015 12:44 PM by Tugdual.)
Post: #12
 Tugdual Senior Member Posts: 756 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
(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/Calc...mance.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.
02-15-2015, 12:54 PM
Post: #13
 Thomas Klemm Senior Member Posts: 1,447 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
(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
02-15-2015, 03:30 PM
Post: #14
 rprosperi Senior Member Posts: 5,069 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
(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.

--Bob Prosperi
02-15-2015, 03:45 PM (This post was last modified: 02-15-2015 03:54 PM by Tugdual.)
Post: #15
 Tugdual Senior Member Posts: 756 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
(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.
02-15-2015, 04:12 PM
Post: #16
 rprosperi Senior Member Posts: 5,069 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
(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!

--Bob Prosperi
02-15-2015, 05:00 PM
Post: #17
 Thomas Klemm Senior Member Posts: 1,447 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
(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.
02-15-2015, 05:17 PM (This post was last modified: 02-15-2015 05:41 PM by Tugdual.)
Post: #18
 Tugdual Senior Member Posts: 756 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
(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...
02-15-2015, 05:57 PM
Post: #19
 Thomas Klemm Senior Member Posts: 1,447 Joined: Dec 2013
RE: Simulating 15C RAN # on 35s
(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
 « Next Oldest | Next Newest »

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