For natural number input N the programme returns the Nth repdigit number in human readable form, eg
for input
19531808
the programme returna
{8 2170201}
to be read as the figure eight repeated 2170201 times.
http://oeis.org/A010785
Size: 94.500
CkSum: # C8AEh
Code:
::
CK1&Dispatch
# FF
::
::
FPTR2 ^DupQIsZero?
case
ZINT 0
ZINT 9
FPTR2 ^ZDIVext
FPTR2 ^DupQIsZero?
NOT?SEMI
DROP
ZINT 1
FPTR2 ^RSUBext
ZINT 9
;
SWAP
ZINT 1
FPTR2 ^RADDext
TWO{}N
;
;
The following User RPL program seems to produce the same outputs as your program, except for most inputs less than 1, which seems to me to be an acceptable limitation.
\<< 1 - 9 IDIV2 SWAP 2 \->LIST -1 - \>>
BYTES: 35.5
CRC: #3E16h
Thank you, Joe, for the clarity of your programme.
For the 33s the programme A produces a 2-level version of the repdigit & programme B takes the result of A & returns the position in the OEIS series.
Preserves stack.
Code:
1. LBL A
2. x<0?
3. GTO B
4. STO N
5. 9
6. STO I
7. INT/
8. STO Q
9. CLx
10. RCL N
11. RCL I
12. RMDR
13. STO R
14. SGN
15. STO+ Q
16. x≠0?
17. RCL* R
18. x=0?
19. RCL+ I
20. RCL Q
21. RTN
1. LBL B
2. +/-
3. STO N
4. SGN
5. STO- N
6. CLx
7. 9
8. RCL* N
9. +
10. RTN
A: LN = 75
B: LN = 42
Slightly improved 33s programme, also deals correctly with 0 as input.
Code:
1. LBL A
2. x<0?
3. GTO B
4. STO N
5. 9
6. STO I
7. INT/
8. STO Q
9. RCL* I
10. +/-
11. RCL+ N
12. STO R
13. SGN
14. STO+ Q
15. x≠0?
16. RCL* R
17. x=0?
18. RCL+ I
19. RCL Q
20. x≠0?
21. RTN
22. x<>y
23. SGN
24. RTN
1. LBL B
2. +/-
3. STO N
4. SGN
5. STO- N
6. CLx
7. 9
8. RCL* N
9. +
10. RTN
A: LN = 84
B: LN = 42
Joe, I have adapted your suggestion for 33s & come up with
Code:
1. LBL C
2. 1
3. -
4. STO N
5. 9
6. RMDR
7. 1
8. +
9. IDIV(N:9)+1
10. RTN
which gives wrong answers, eg
8
111111111112
for input
999999999998
whereas my programme returns correct
8
111111111111
Is my implementation faulty?
(10-13-2022 07:06 AM)Gerald H Wrote: [ -> ]...
...
which gives wrong answers, eg
8
111111111112
for input
999999999998
whereas my programme returns correct
8
111111111111
Is my implementation faulty?
No, you ran into a bug in the 33s when it evaluates "equations". If you store 999999999997 into N, then store IDIV(N:9)+1 in EQN, then execute it, the 33s returns the wrong answer (111111111112), whereas the 35s returns the correct answer (111111111111). Furthermore, the 33s returns the correct answer if you rewrite the program without using the EQN key.
I do not not know whether this bug in the 33s has been found before, or if you are its first discoverer.
Edit: Line 14 corrected.
Yes, now gives correct answers.
Code:
1. LBL C
2. 1
3. STO U
4. -
5. STO N
6. 9
7. STO I
8. INT/
9. RCL+ U
10. x<> N
11. RCL I
12. RMDR
13. RCL+ U
14. RCL N
15. RTN
C: LN = 69