Simulating 15C RAN # on 35s

[Tugdual]

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

[Namir]

The expression:

Frac(1574352261*0.8603685347)

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

Namir

[Tugdual]

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.

[Paul Dale]

Shouldn't there be a FRAC surround the entire expression?
Regardless of the need for the FRAC around the multiplication.


- Pauli

[Thomas Klemm]

(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

[Tugdual]

@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!

[Thomas Klemm]

(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

[Tugdual]

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

[Paul Dale]

What about the checksum?????


Pauli

[Thomas Klemm]

(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

[Tugdual]

(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.

[Tugdual]

(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.

[Thomas Klemm]

(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

[rprosperi]

(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.

[Tugdual]

(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.

[rprosperi]

(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!

[Thomas Klemm]

(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.

[Tugdual]

(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...

[Thomas Klemm]

(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