The Museum of HP Calculators

HP Forum Archive 21

[ Return to Index | Top of Index ]

HHC 2013 programming contest winners
Message #1 Posted by Brian Walsh on 22 Sept 2013, 4:57 p.m.

RPL - Bill Butler

RPN - Eric Smith

Eric's solution was 19 steps and used no data storage registers.

Edited: 22 Sept 2013, 4:57 p.m.

      
Re: HHC 2013 programming contest winners
Message #2 Posted by Eric Smith on 22 Sept 2013, 4:59 p.m.,
in response to message #1 by Brian Walsh

My RPN entry as submitted was:

HHC 2013 RPN Programming Contest entry
Eric Smith <spacewar@gmail.com>
September 21, 2013

WP-34S version:

01: CONST #000
02: CONST #001
03: LBL 01
04: RCL Z
05: x = 0?
06: GTO 02
07: IP
08: STO- T
09: RCL* Y
10: STO+ Z
11: RDN
12: CONST #010
13: STO* T
14: CLx
15: CONST #008
16: /
18: GTO 01
18: LBL 02
19: RCL Z


HP-42S and HP-41:  replace CONST lines with ordinary numeric entry lines

HP-41C:  replace "RCL* Y" with "x<>y  STO* Y  x<>y"
            
Re: HHC 2013 programming contest winners
Message #3 Posted by Miguel Toro on 24 Sept 2013, 12:27 p.m.,
in response to message #2 by Eric Smith

Hi Eric,

There may be an error on the transcription of your solution. When I try it as written in your post, the value in T is lost after 12: and the program returns always 1.

If, for example, I make the following change, then the program runs correctly :

01: c# 001      (saves one step)
02: LBL 01
03: RCL Z
04: x = 0?
05: GTO 02
06: IP
07: STO- T
08: RCL* Y
09: STO+ Z
10: RDN
11: x <> T
12: SDL 001
13: STO T
14: CLx
15: CONST #008
16: /
17: GTO 01
18: LBL 02
19: RCL Z

Or perhaps there is something I am not seeing? Forgive me if am mistaken.

Miguel

                  
Re: HHC 2013 programming contest winners
Message #4 Posted by Gerson W. Barbosa on 24 Sept 2013, 1:34 p.m.,
in response to message #3 by Miguel Toro

CLx after STO* T is not disabling the stack lift as it should. Same here (v3.2r3382), but it does work on the emulator and on the HP-42S. Probably an old wp34s bug that's already been fixed. What is the version of your wp34s?

Best regards,

Gerson

PS.: This is Eric's program optimized for the wp34s:

01: CPX CONST #001              ;   CPX 1
02: RCL Z
03: x = 0?
04: SKIP 11
05: IP
06: STO- T
07: RCL* Y
08: STO+ Z
09: RDN
10: CONST #010
11: STO* T
12: CLx
13: CONST #008
14: /
15: BACK 013
16: RCL Z

Edited: 24 Sept 2013, 1:57 p.m.

                        
Re: HHC 2013 programming contest winners
Message #5 Posted by Dieter on 24 Sept 2013, 2:01 p.m.,
in response to message #4 by Gerson W. Barbosa

Quote:
CLx after STO* T is not disabling the stack lift as it should. Same here (v3.2r3382), but it does work on the emulator and on the HP-42S. Probably an old wp34s bug that's already been fixed.
Indeed. Everything works fine on my hardware 34s with v. 3.2 3405.

Dieter

                        
Re: HHC 2013 programming contest winners
Message #6 Posted by Miguel Toro on 24 Sept 2013, 2:03 p.m.,
in response to message #4 by Gerson W. Barbosa

Hello Gerson,

I am using V 3.2 3450. Physical device (not the emulator).

Regards,

Miguel

                              
Re: HHC 2013 programming contest winners
Message #7 Posted by Gerson W. Barbosa on 24 Sept 2013, 2:13 p.m.,
in response to message #6 by Miguel Toro

Strange, that's more recent than the emulator version (3448).

Regards,

Gerson.

P.S.: Eric Smith's solution works for arguments up to 7.77777777777

3.11037552421  -->  3.14159265358
7.77777777777  -->  7.99999999988

Edited: 24 Sept 2013, 3:07 p.m.

                                    
Re: HHC 2013 programming contest winners
Message #8 Posted by Miguel Toro on 24 Sept 2013, 3:40 p.m.,
in response to message #7 by Gerson W. Barbosa

Well, I really do not get it. Could someone try it with version 3.2 3450 ? I think it is behaving correctly:

Suppose x = 0.5 						

    t:	 -    -   0.5   0.5   0.5   0.5   0.5   0.5   0.5   0.5    0  <-- value lost after 10: const #10
    z:	 -   0.5   0     0     0     0     0     0     0     0     1
    y:	 -    0    1     1     1     1     1     1     1     1     0
    x:	0.5   1   0.5   0.5   0.5    0     0     0     0     0    10
steps: 	 -   01   02    03    04    05    06    07    08    09    10

I do not think it is because of the CLx not disabling the stack lift. The version on post #2, works because Clx disable the stack lift

Edited: 24 Sept 2013, 3:45 p.m.

                                          
Re: HHC 2013 programming contest winners
Message #9 Posted by Gerson W. Barbosa on 24 Sept 2013, 4:20 p.m.,
in response to message #8 by Miguel Toro

Hello Miguel

Quote:
I do not think it is because of the CLx not disabling the stack lift.

You are right. It turns out I was getting wrong results on the wp34c because my last line was RCL 2 instead of RCL Z. Sorry about the confusion. I will check it again step by step.

Gerson.

P.S.:

Quote:
The version on post #2, works because Clx disable the stack lift

I meant CLx disabled the stack lift (so that 8 replaces the 10 that was previously there).

Edited: 24 Sept 2013, 4:32 p.m.

                                          
Re: HHC 2013 programming contest winners
Message #10 Posted by Gerson W. Barbosa on 24 Sept 2013, 4:28 p.m.,
in response to message #8 by Miguel Toro

Aren't you confusing RDN with RND? In Eric Smith's notation RDN means Rv (Roll stack down). That's the first thing I had checked previously, but I didn't detect it because I had introduced an error myself.

Regards,

Gerson.

Edited: 24 Sept 2013, 4:29 p.m.

                                                
Re: HHC 2013 programming contest winners
Message #11 Posted by Paul Dale on 24 Sept 2013, 5:20 p.m.,
in response to message #10 by Gerson W. Barbosa

Or you could use DROP instead of Rv in this instance. It will also be imperceptibly faster.

At one point we had a display of program checksums in the 34S firmware which would help avoid this kind of thing. I don't remember exactly why they were removed -- I suspect due to opcodes changing but aren't certain anymore.

- Pauli

                                                
Re: HHC 2013 programming contest winners
Message #12 Posted by Miguel Toro on 24 Sept 2013, 8:42 p.m.,
in response to message #10 by Gerson W. Barbosa

Yes. I was confusing those two and confused myself :-)

Thank you Gerson.

Regards,

Miguel

                        
Re: HHC 2013 programming contest winners
Message #13 Posted by Dieter on 24 Sept 2013, 5:28 p.m.,
in response to message #4 by Gerson W. Barbosa

For the record: this one is even one step shorter. 

01: CPX CONST #001
02: RCL Z
03: x = 0?
04: SKIP 10
05: IP
06: STO- T
07: RCL* Y
08: STO+ Z
09: X<> T
10: SDL 001
11: CONST #008
12: STO/ Z
13: <> ZTYY
14: BACK 012
15: RCL Z
Yes, I like these 34s stack shuffle commands. :-)

Dieter

                              
Re: HHC 2013 programming contest winners
Message #14 Posted by Gerson W. Barbosa on 25 Sept 2013, 1:21 a.m.,
in response to message #13 by Dieter

Quote:
Yes, I like these 34s stack shuffle commands. :-)

Me too, but they won't help here, it appears.

Gerson. 

001  SDR 001
002  C #001
003  RCL Z
004  SDL 001
005  IP 
006  t<> L
007  RCL* Y
008  STO+ Z
009  DROP
010  8
011  /
012  R^
013  FP 
014  x#0?
015  BACK 011
016  RCL Z

Edited to correct misspelling.

Edited: 25 Sept 2013, 2:41 p.m. after one or more responses were posted

                                    
Re: HHC 2013 programming contest winners
Message #15 Posted by Paul Dale on 25 Sept 2013, 1:48 a.m.,
in response to message #14 by Gerson W. Barbosa

This piece of code almost makes me wish I'd implemented the integer mode shifts in real mode too :)

- Pauli

                                          
Re: HHC 2013 programming contest winners
Message #16 Posted by Gerson W. Barbosa on 25 Sept 2013, 2:45 p.m.,
in response to message #15 by Paul Dale

SDL and SDR are great but binary shifts would be handy in a lot of situations as well. No more room or just a matter of design philosophy?

Gerson.

                                                
Re: HHC 2013 programming contest winners
Message #17 Posted by Paul Dale on 25 Sept 2013, 5:43 p.m.,
in response to message #16 by Gerson W. Barbosa

A bit of both really. Flash is basically full so finding space would take lots of effort or lose something else.

We'd also have had to convince Walter that they were useful (well, Marcus and I would also need convincing too I suspect). Two of the shifts would map to *2^x and /2^x in real mode and the rest still do nothing introducing a small inconsistency.

The alternative is 2^x * or 2^x / so these would only save one step. There would only be a performance boost if the algorithm were coded to deal with integers only -- either another inconsistency or more core. Both options are bad.

- Pauli

                                                      
Re: HHC 2013 programming contest winners
Message #18 Posted by Dieter on 26 Sept 2013, 8:19 a.m.,
in response to message #17 by Paul Dale

While bit shifts for reals would be nice, I personally do not see a big advantage for real life applications. With one exception: doubling or halving a number is a common operation. A dedicated command (if possible, without affecting the stack) would add very nicely to the existing INC and DEC commands. Yes, we already had that discussion some time ago, but I still consider such commands very useful for every-day-programming. So please forgive me if I dig out this idea once again.

Dieter

      
Re: HHC 2013 programming contest winners
Message #19 Posted by Egan Ford on 22 Sept 2013, 5:14 p.m.,
in response to message #1 by Brian Walsh

Congrats Bill and Eric.

Now that the contest is over I guess we can share our results.

I selected to use the 12C because it was designed to solve this problem (indirectly of course :-).

Embedded in the 12C is the following function:

To use: set CF0 to 0, then set CFj (j=1 to n number of digits) to each octal-decimal digit, then set your base (-1 then 100x), and then press NPV.

Code:

01 -    43 25  INTG        ; LSTx = x, x = int(x) (0 or 1)
02 -    43 35  x=0         ; if x=0
03 - 43,33 05  GTO 05      ;   then LSTx < 1, continue with x = 0
04 - 43,33 00  GTO 00      ;   else end program and leave x = 1
05 -    43 13  CFo         ; x = 0, CFo = x, n = 1
06 -    43 36  LSTx        ; x = LSTx
07 -    43 35  x=0         ; if x=0
08 - 43,33 17  GTO 17      ;   then no digits left, continue with NPV setup and NPV
09 -        1  1           ; x = x * 10
10 -        0  0           ;
11 -       20  x           ;
12 -       36  ENTER       ; y = x
13 -    43 24  FRAC        ; x = value right of decimal
14 -       30  -           ; x = y - x, i.e. value left of decimal, LSTx = right of decimal
15 -    43 14  CFj         ; CFn = int(x), n = n + 1
16 - 43,33 06  GTO 06      ; loop up for next digit
17 -        7  7           ; sto 700 in i
18 -        0  0           ;   NOTE: i = i / 100
19 -        0  0           ;
20 -       12  i           ;
21 -    42 13  NPV         ; do it, x = answer

Thanks again Gene for the challenge. It was fun to finally use NPV.

      
Re: HHC 2013 programming contest winners
Message #20 Posted by Paul Dale on 22 Sept 2013, 5:18 p.m.,
in response to message #1 by Brian Walsh

WP34S program. Seventeen steps. Executition time three ticks for any input.

	# 099		// Scaling factor
	STO K		// Into loop counting register
	# 000		// Result
	RCL Z		// Stack rearrangement to get the input in X
	SDL[->]K	// Scale the input
			// Add IP here to avoid problems for 10^-100 arguments
	RCL X		// Begin loop
	# 010		// Extract lowest digit
	MOD
	RCL+ T		// Accumulate digit into result
	# 008		// Push result one octal digit
	/
	x[<->] Y	// Get original number back
	SDR 001		// Shift it and trim final digit off
	IP
	DSZ K		// Loop until done
	BACK 010
	+		// Could use x[<->] Y here but that doesn't handle 1 as input

Some results:

Input		Result			True			Delta
0.5		0.625			0.625			0
0.75		0.953125		0.953125		0
0.1		0.125			0.125			0
0.777777777	0.9999999925494194	0.9999999925494194	0
0		0			0			0
1		1			1			0
1e-95		1.60861174670876E-86	1.608611746708759E-86	1e-101

This routine handles inputs from 1e-99 through 1 plus 0. The range can be altered by changing the constant on the first line, decreasing this reduces execution time. E.g. if the lower limit is restricted to 1e-16, change this constant to 16 and the execution time will be essentially zero.

Take the LBLs out of Eric's solution using BACK and SKIP and his program is one step shorter than this and a bit faster.

- Pauli

Edited: 22 Sept 2013, 5:30 p.m.

            
Re: HHC 2013 programming contest winners
Message #21 Posted by Eric Smith on 22 Sept 2013, 6:29 p.m.,
in response to message #20 by Paul Dale

One of the things I like about the programming challenges is that I always learn new techniques from the other participants. Even though I had the winning RPN entry this year, and used a WP-34S, I wasn't familiar with the SDL, SDR, SKIP, and BACK instructions.

My program produces correct results over the domain [0 to 7.777...]

            
Re: HHC 2013 programming contest winners
Message #22 Posted by Marcel Samek on 23 Sept 2013, 2:56 a.m.,
in response to message #20 by Paul Dale

Although my stab at this uses 3 registers, it did come in at 15 steps on the WP-34S. It handles values down to 1e-99

CLREGS
INC 00
STO 01
x=0?
SKIP 009
IP
RCL/ 00
STO+ 02
8
STOx 00
RCL 01
FP
SDL 001
BACK 011
RCL 02
                  
Re: HHC 2013 programming contest winners
Message #23 Posted by Gerson W. Barbosa on 23 Sept 2013, 11:51 a.m.,
in response to message #22 by Marcel Samek

No numbered register was killed during the execution of this program, but down to 17 steps only: 

001   C# 001
002   RCL Z
003   SDL 001
004   IP
005   8
006   STO* Z
007   Rv
008   t<> L
009   RCL/ Y
010   STO+ Z
011   <-> TYZT
012   FP
013   x#0?
014   BACK 011
015   RCL Z
016   x>1?
017   IP


0.11037552421  -->  0.14159265358
            
Re: HHC 2013 programming contest winners
Message #24 Posted by Gerson W. Barbosa on 23 Sept 2013, 8:44 a.m.,
in response to message #20 by Paul Dale

Quote:
Take the LBLs out of Eric's solution using BACK and SKIP and his program is one step shorter than this and a bit faster.

One more step can be save by replacing steps 001 and 002 with 

01: C# 001
                  
Re: HHC 2013 programming contest winners
Message #25 Posted by Paul Dale on 23 Sept 2013, 7:33 p.m.,
in response to message #24 by Gerson W. Barbosa

The baton has passed. Others are exploiting the 34S function set better than I :-)

Congratulations to all,

Pauli

      
Re: HHC 2013 programming contest winners
Message #26 Posted by Gerson W. Barbosa on 22 Sept 2013, 5:53 p.m.,
in response to message #1 by Brian Walsh

Here are mine: 

WP-34S:

001   # 000
002   # 008
003   RCL Z
004   SDL 001
005   IP
006   STO+ Z
007   8
008   STO* T
009   STO* Z
010   Rv
011   x<> L
012   FP
013   x#0?
014   BACK 010
015   Rv
016   /
017   x>1?
018   IP


HP-15C:

001- f MATRIX 1
002- f LBL 0
003-   8
004-   STO* 1
005-   x<>y
006-   1
007-   0
008-   *
009- g INT
010-   RCL/ 1
011-   STO- 0
012-   LSTx
013-   f FRAC
014-   g TEST 0
015-   GTO 0
016-   1
017-   RCL 0
018- g TEST 2
019- g INT
020-   -
            
Re: HHC 2013 programming contest winners
Message #27 Posted by Gerson W. Barbosa on 24 Sept 2013, 6:28 p.m.,
in response to message #26 by Gerson W. Barbosa

Quote:
001   # 000
002   # 008

These can of course be replaced with

Quote:
001   C# 008

QBASIC equivalent of the first program: 

DEFDBL A-Z
DEFINT D
DEF FNFRAC (NN) = NN - INT(NN)
CLS
INPUT N
P = 8
S = 0
DO
  N = 10 * N
  D = INT(N)
  P = P * 8
  S = 8 * (S + D)
  N = FNFRAC(N)
LOOP UNTIL N = 0
R = S / P
IF R > 1 THEN R = 1
PRINT R

? 0.11037552421
 .141592653584667

      
Re: HHC 2013 programming contest winners
Message #28 Posted by Eric Smith on 22 Sept 2013, 6:33 p.m.,
in response to message #1 by Brian Walsh

My (non-winning) RPL entry was:

148 bytes (not including a global name)

« UNROT
   « { } SWAP 1 12 START
    10 DUP2 MOD UNROT / IP UNROT + SWAP
    NEXT DROP »
  ROT OVER EVAL UNROT EVAL
  ADD SWAP MOD REVLIST
  « SWAP 10 * + » STREAM
»

An earlier version used a logarithm to determine how many digits to use, but I made the tradeoff of assuming 12 digits for a slightly shorter program. Bill Butler's winning program is shorter than mine ever though it does compute the digit count with a logarithm.

Edited: 22 Sept 2013, 6:33 p.m.

            
Re: HHC 2013 programming contest winners
Message #29 Posted by Eddie W. Shore on 22 Sept 2013, 10:31 p.m.,
in response to message #28 by Eric Smith

My RPL entry was (didn't win, I got it down to 168.5 bytes) - HP 50g

<< 'N' STO 0 UNROT
DUP2 XPON SWAP XPON
MAX 1 + 1 SWAP FOR
K DUP2 K ALOG / FP
1 ALOG * IP SWAP K
ALOG / FP 1 ALOG *
IP + N MOD K 1 - ALOG
4 ROLL + UNROT NEXT
DROP2 { N K } PURGE >>
      
Re: HHC 2013 programming contest winners
Message #30 Posted by Gerson W. Barbosa on 22 Sept 2013, 10:50 p.m.,
in response to message #1 by Brian Walsh

An RPL solution (HP 50g) to the RPN problem. The handling of 0 and 1 cases is left as an exercise to the reader. 

%%HP: T(3)A(R)F(.);
\<< \->STR TAIL DUP SIZE SWAP "o" "# " ROT + SWAP + OBJ\-> B\->R 8. ROT ^ /
\>>

(63.5 bytes)

Input		Result			
0.5		0.625			
0.75		0.953125		
0.1		0.125			
0.777777777	0.9999999925494

Gerson.

            
Re: HHC 2013 programming contest winners
Message #31 Posted by Paul Dale on 22 Sept 2013, 10:54 p.m.,
in response to message #30 by Gerson W. Barbosa

Does this handle 1e-50 ?

- Pauli

                  
Re: HHC 2013 programming contest winners
Message #32 Posted by Gerson W. Barbosa on 22 Sept 2013, 11:02 p.m.,
in response to message #31 by Paul Dale

Only decimal numbers from 0.000000000001 through 0.777777777777, in this format only (the first zeroes may be omitted).

Gerson.

Edited: 22 Sept 2013, 11:04 p.m.

      
Re: HHC 2013 programming contest winners
Message #33 Posted by Jim Horn on 23 Sept 2013, 12:16 p.m.,
in response to message #1 by Brian Walsh

I played with a few line non-iterated RPN approach which would use a built in octal to decimal conversion: Multiply by 10^n (with n=number of digits for that calculator's precision) convert that integer from octal to decimal divide by 8^n But, to my surprise, I don't see any RPN machines with base conversion except for display values only. So step 2 isn't available, even though the actual math is in many of them.

My congradulations to the winners - and all who submitted entries!

            
Re: HHC 2013 programming contest winners
Message #34 Posted by Gerson W. Barbosa on 23 Sept 2013, 12:32 p.m.,
in response to message #33 by Jim Horn

That's what I have in my HP-41C with the Advantage Module right now:

01  OCTIN
02  ENTER^
03  LN
04  8
05  LN
06  / 
07  1
08  +
09  INT
10  8
11  X<>Y
12  Y^X
13  /

        R/S 5 R/S  -->  0.625000000
       R/S 75 R/S  -->  0.953125000
R/S 777777777 R/S  -->  0.999999993

Obviously 0 and 1 are not possible here.

Gerson.

Edited: 23 Sept 2013, 12:33 p.m.

                  
Re: HHC 2013 programming contest winners
Message #35 Posted by Dieter on 24 Sept 2013, 8:01 a.m.,
in response to message #34 by Gerson W. Barbosa

I am always very careful with INT commands following transcendetal functions like the logarithm here. Unexpected behaviour may occur due to roundoff errors. Your program evaluates the base-8 log - which may cause such a problem: 

  8 ENTER 7 yx
    => 2097152
  [LN]
    => 14,56609079     ; rounded down from ...79 17588 ...
  8 [LN]
    => 2,079441542     ; rounded up from ...41 67983 ...
  [/]
    => 6,999999998     ; so the quotient is below the true value
                         and INT(x) becomes 6 instead of 7
I do not know if this will also happen with the program you posted (my HP41 does not have an Advantage ROM, and I do not even know what exactly the OCTIN command does), but maybe you can try some integer powers of 8. If roundoff errors occur, using [LOG] instead of [LN] may give better results since lg 8 rounds much better to ten digits than ln 8.

Dieter

                        
Re: HHC 2013 programming contest winners
Message #36 Posted by Gerson W. Barbosa on 24 Sept 2013, 10:25 a.m.,
in response to message #35 by Dieter

OCTIN allows for the input of integer octal constants. For instance: 

keystrokes                               display    
            
XEQ ALPHA OCTIN ALPHA                      _ O
75301 ENTER^                             31425        ; 753018 = 3142510

However a better program (better if DEC were not natively available) would be: 

01  OCTIN
02  1073741824              ; 8^10
03  /

R/S 5000000000 R/S  -->  0.625000000
R/S 7500000000 R/S  -->  0.953125000
R/S 7777777770 R/S  -->  0.999999993   
R/3 7777777777 R/S  -->  0.999999999

Gerson.

Edited: 24 Sept 2013, 10:25 a.m.

            
Re: HHC 2013 programming contest winners
Message #37 Posted by Paul Dale on 23 Sept 2013, 7:32 p.m.,
in response to message #33 by Jim Horn

Isn't this the basis for the five step 41 program? Using the OCT and DEC functions?

If not, I'd like to know how they were done.

- Pauli

            
Re: HHC 2013 programming contest winners
Message #38 Posted by Olivier De Smet on 24 Sept 2013, 2:53 a.m.,
in response to message #33 by Jim Horn

You can have on HP41 (naked) and also on HP65 (but in 20 steps)

01 1E10
02 *
03 DEC
04 1073741824
05 /

But that's cheating as told previously

(to have 1 working, use 1E9 and 134217728)

Edited: 24 Sept 2013, 3:28 a.m. after one or more responses were posted

                  
Re: HHC 2013 programming contest winners
Message #39 Posted by Paul Dale on 24 Sept 2013, 2:59 a.m.,
in response to message #38 by Olivier De Smet

Thanks, it is as I thought.

- Pauli

                  
Re: HHC 2013 programming contest winners
Message #40 Posted by Gerson W. Barbosa on 24 Sept 2013, 7:48 a.m.,
in response to message #38 by Olivier De Smet

Quote:
But that's cheating as told previously

Why? Rule #4 says:

"No custom built ROM or machine code can be built and used for this problem. Any already existing functionality in the machine is ok."

I wasn't aware of that function, but DEC (octal to decimal conversion) is part of the HP-41 instruction set. So, that should be ok, except for the 1 case. Likewise, the equivalent HP-42S program should be ok too: 

01 1E12
02 *
03 ->DEC
04 68719476736
05 /

                        
Re: HHC 2013 programming contest winners
Message #41 Posted by gene wright on 24 Sept 2013, 8:35 a.m.,
in response to message #40 by Gerson W. Barbosa

True, but that is why at the conference I had to put up some rule clarifications...such as

No base conversion functions allowed.

Wlodek came up with the large constant similar to what you indicated, but to keep things "fair" between machines, no base conversion functions were allowed.

We had entries for these machines:

HP 65 !

HP 29C

HP 41CX

HP 42S

WP 34S

HP 15c LE (by Bill Carter!) oops.

I especially like Egan's 12c approach. Fascinating! Wish you had been at the conference this year!

Thanks again all. I hope these problems were interesting.

Edited: 25 Sept 2013, 8:23 a.m. after one or more responses were posted

                              
Re: HHC 2013 programming contest winners
Message #42 Posted by Gerson W. Barbosa on 24 Sept 2013, 9:52 a.m.,
in response to message #41 by gene wright

Quote:
at the conference I had to put up some rule clarifications...such as

No base conversion functions allowed.

Eric Smith said in another thread: "There was another rules clarification at the conference that no base conversion functions can be used." I'd forgotten about that, sorry!

Quote:
Wlodek came up with the large constant similar to what you indicated,

That's 8^12, as Jim Horn has suggested. I kind of found the trick but I dumbly used different constants, according to the number of significant digits rather than the machine's number of digits.

Quote:
I especially like Egan's 12c approach. Fascinating!

Really fascinating, as non-conventional approaches usually are!

Quote:
Wish you had been at the conference this year!

I visited a forum member last month and I asked him about going to the next year's conference. He told me his English was not good enough to fully enjoy it. I told him not to worry much about that, but on second thought I realize I would need to go at least one month in advance to get used to spoken language. I still watch American movies with English subtitles on :-)

Thanks again for the interesting problems. They have the right difficulty level, the real challenge being size (or speed) optimization.

Gerson.

                              
Re: HHC 2013 programming contest winners
Message #43 Posted by Paul Dale on 24 Sept 2013, 4:18 p.m.,
in response to message #41 by gene wright

Programs using DEC or ->DEC aren't going to correctly deal with really small numbers in the [0, 1] interval. Try 1e-50 and see what happens.

Actually, they might be able to with some extra steps -- get the exponent via LOG and IP. Then use these to calculate the required constants instead of hard coding them. I suspect this will still be shorter than the digit by digit approaches.

- Pauli

Edited: 24 Sept 2013, 4:19 p.m.

                                    
Re: HHC 2013 programming contest winners
Message #44 Posted by David Hayden on 24 Sept 2013, 10:34 p.m.,
in response to message #43 by Paul Dale

Quote:
get the exponent via LOG and IP.
Or use EXPT and MANT to get the exponent and mantissa directly.

By the way, I noticed an inconsistency between the 34S manual and the software. On the last page of my manual (3.18 3242) it says that in version 3.0, "returned ->BIN, ->HEX, and ->OCT." These commands were removed in v2.1. But I can't find these commands in any of the menus or in the manual. Were they removed again?

Dave

                                          
Re: HHC 2013 programming contest winners
Message #45 Posted by Paul Dale on 24 Sept 2013, 11:12 p.m.,
in response to message #44 by David Hayden

I don't remember what happened to these commands. I think we removed them because they didn't achieve anything useful -- it is easier to switch integer mode and switch back when done rather than introducing extra complexity in the display code. Walter might remember better.

I'm not sure I'd call this an inconsistency. These aren't documented in the command listing and the change log is known to not be totally complete and accurate. There have been a lot of changes and refinements and not everything made the last page.

- Pauli

                              
Re: HHC 2013 programming contest winners
Message #46 Posted by Bill Carter on 24 Sept 2013, 11:50 p.m.,
in response to message #41 by gene wright

Gene-

No love at all for the 15c entrant? I'm not sure my wife really believes my account of where I was all weekend as it is!

-Bill

Edited: 25 Sept 2013, 12:05 a.m.

                              
Re: HHC 2013 programming contest winners
Message #47 Posted by Egan Ford on 25 Sept 2013, 12:00 a.m.,
in response to message #41 by gene wright

Quote:
I especially like Egan's 12c approach.
Glad you liked it. When I read the challenge and given your financial background I had assumed you had NPV in mind.

Updated version that should support 0 through 7777777777 including fractional. I didn't have a lot of time to test or optimize it. Perhaps another day. 

01 -    43 25  INTG        
02 - 44 48  1  STO .1      
03 -    43 35  x=0         
04 - 43,33 21  GTO 21      
05 -    43 36  LSTx        
06 -        1  1           
07 -        0  0           
08 -    43 36  LSTx        
09 -    43 23  LN          
10 -        1  1           
11 -        0  0           
12 -    43 23  LN          
13 -       10  /           
14 -    43 25  INTG        
15 -        1  1           
16 -       40  +           
17 - 44 48  1  STO .1      
18 -       21  y^x         
19 -       10  /           
20 -    43 25  INTG        
21 -    43 13  CFo         
22 -    43 36  LSTx        
23 -    43 35  x=0         
24 - 43,33 33  GTO 33      
25 -        1  1           
26 -        0  0           
27 -       20  x           
28 -       36  ENTER       
29 -    43 24  FRAC        
30 -       30  -           
31 -    43 14  CFj         
32 - 43,33 22  GTO 22      
33 -        7  7           
34 -        0  0           
35 -        0  0           
36 -       12  i           
37 -    42 13  NPV         
38 -        8  8           
39 - 45 48  1  RCL .1      
40 -       21  y^x         
41 -       20  x
                                    
Re: HHC 2013 programming contest winners
Message #48 Posted by Gerson W. Barbosa on 25 Sept 2013, 1:08 a.m.,
in response to message #47 by Egan Ford

HP-15C version as of last Sunday:

001- g x=0
002- g RTN
003-   EEX
004-   9
005-   *
006-   STO RAN#
007- g LOG
009- g INT
009-   8
010-   -
011-   8
012-   x<>y
013-   y^x
014-   STO 1
015- g CLx
016-   STO 0
017-   RCL RAN#
018- f LBL 0
019-   1
020-   0
021-   *
022- g INT
023-   8
024-   STO/ 1
025-   x<>y
026-   RCL* 1
027-   STO+ 0
028- g LSTx
029- f FRAC
030- g TEST 0
031-   GTO 0
032-   RCL 0


 7777777777  -->  1073741823
    1234567  -->  342391.0000
3.110375524  -->  3.141592651
                                          
Re: HHC 2013 programming contest winners
Message #49 Posted by Gerson W. Barbosa on 25 Sept 2013, 6:08 p.m.,
in response to message #48 by Gerson W. Barbosa

From my integer base conversion routine circa 1984, so some optimization is possible.

001- f LBL B		; define base
002-   STO .0
003- g LOG
004- g INT
005-   1
006-   +
007-   STO .1
008-   RCL .0
009- g RTN

010- f LBL E		; convert from decimal to defined base
011-   STO 1
012-   0
013-   STO I 
014-   STO 2
015- f LBL 4
016-   RCL 1
017- g INT
018-   RCL/ .0
019-   STO 1
020- f FRAC
021-   RCL* .0
022-   RCL I
023-   10^x
024-   *
025-   STO+ 2
026-   RCL .1
027-   STO+ I
028-   RCL 1
029-   GTO 4
030-   RCL 2
031- g RTN

8 GSB B  -->  8.000000000 	; octal base

    342391 GSB E  -->  1234567.000
1073741823 GSB E  -->  7777777778	; the last digit should be a 7
     25894 GSB E  -->  62446.00000

16 GSB B --> 16.00000000	; hexadecimal base

     99774 GSB E  -->  108051114	; 1.08.05.11.14, that is, 185BE

257 GSB B --> 257.0000000	; base 257

  12345678  GSB E  -->  186235169.0     ; 186.235.169257     
 123456789  GSB E  -->  7070043158      ; 7.070.043.158257          ; the last digit should be a 7

This is subject to rounding error for large inputs, as we can see from the examples. I used it mainly for decimal to hexadecimal conversions -- no problem in the short range I used. Someone ought to have told me there was something called HP-16C :-)

Edited: 25 Sept 2013, 6:12 p.m.

                  
Re: HHC 2013 programming contest winners
Message #50 Posted by cyrille de brebisson on 25 Sept 2013, 3:08 p.m.,
in response to message #38 by Olivier De Smet

Hello,

Here is some HP Prime code for both contests. Both are solved in 1 line of code (plus declarations) and no loops (at least that meets the eye).

note: replace SigmaList byt he appropriate symbol

export RplProgContest(Base, X, Y) begin SigmaList(((makelist(ip(fp(X:=X/10)*10),C,1,12)+ makelist(ip(fp(Y:=Y/10)*10),C,1,12)) mod Base)* {1,10,100,1000,10000,100000,..,100000000000}); end;

note, you can replace the {1,10..} by makelist(10^A,A,0,11), smaller, but slower

export RpnProgContest(X) begin SigmaList(makelist((ip(X) mod 10)*1/8^C + (0*(X:=X*10)),C,0,12)); end;

Cyrille

                        
Re: HHC 2013 programming contest winners
Message #51 Posted by Geoff Quickfall on 30 Sept 2013, 10:58 p.m.,
in response to message #50 by cyrille de brebisson

That's a heck of a single line of code Cyrille!

:-)

How are the renovations going?

Geoff

                        
Re: HHC 2013 programming contest winners
Message #52 Posted by Gerson W. Barbosa on 1 Oct 2013, 12:27 a.m.,
in response to message #50 by cyrille de brebisson

Quote:
export RpnProgContest(X) begin SigmaList(makelist((ip(X) mod 10)*1/8^C + (0*(X:=X*10)),C,0,12)); end;

Reminds me this can be done on the HP-17BII as well, in one line of code so to say:

0*L(X:X/10)+SIGMA(C:0:11:1:0*L(T:X)+L(X:(IP(10*X)))/8^C+0*L(X:FP(10*G(T))))=D

Gerson.

      
Re: HHC 2013 programming contest winners
Message #53 Posted by David Hayden on 26 Sept 2013, 11:39 p.m.,
in response to message #1 by Brian Walsh

Over the past couple of days I've put together a solution to the RPL problem that takes a different approach. This converts the digits to binary and then does carry-free addition with bit twiddling.

At 281 bytes, it's huge, but because there are NO LOOPS it's very fast.

For base 2 you just XOR the numbers.

For base 8, you covert the octal digits as a hex number (e.g., 77. to #77h), thus there is one extra bit to the left of each octet. Now you can add the numbers and any carry goes into the extra bit, which is then masked out.

Base 10... oh you silly base 10.... As with base 8, I convert the digits in hex mode (e.g., 94. to #94h). So each digit occupies 4 bits. The trick is to add them while subtracting 10 from the sum in such a way that the sum is never greater than 15, which would cause it to spill over to the next digit's bits. If two digits are A and B, the code says "if A is greater than 5 then subtract 5 from it and add 5 to B. If B is now greater than 10 then subtract 10 from it. Now A is in the range [0..5] and B is [0..9], so you can add them and the result is [0..14] which still fits in 4 bits. If the sum is greater than 10 then subtract 10." All of this is done with bit manipulation on all digits simultaneously.

I may write this up in a Datafile article.

Replace the ">" characters with the right arrow. Sorry, I keep forgetting now to convert a listing to ascii. :( 

«
    { { R¨>I ¨>STR "#" SWAP + OBJ¨> }
      SWAP OVER EVAL UNROT EVAL  } @ You now have binaries with the same digits

    SWAP CASE
    DUP 2. == THEN
        @ This is easy. Convert to binary and XOR together
        BIN DROP EVAL
        XOR

    END
    DUP 8. == THEN
        HEX DROP EVAL
        ADD #7777777777777777h AND 

    END
    @ It better be 10
        HEX  DROP EVAL

        DUPDUP SL AND          @ a & (a<<1)
        OVER SR OR #4444444444444444h AND @ x.4 = a.8 | (a.4 & a.2)
        @ level 1 now contains 4 if a>5. subtract from a and add
        @ to b
        SWAP OVER -
        UNROT +
        @ b a
        { DUPDUP SL OR   @ b | (b<<1)
          SL OVER AND    @ b.8 & (b.4 | b.2)
          #8888888888888888h AND
          DUP SR SR OR
          -
        }
        SWAP OVER EVAL      @ sub10(b)
        @ b Sub10 a
        ROT +               @ a+b Sub10
        SWAP EVAL           @ here is the answer, but in hex

    END

    @ Level 1 contains a binary number reprenting the answer.
    @ convert the digits to a real.
    ¨>STR
    DUP SIZE 1. - 2. SWAP SUB    @ take off the h
    OBJ¨>

»

[ Return to Index | Top of Index ]

Go back to the main exhibit hall