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.
HHC 2013 programming contest winners

09222013, 04:57 PM
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.
09222013, 04:59 PM
My RPN entry as submitted was:
HHC 2013 RPN Programming Contest entry
09222013, 05:14 PM
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 CF_{0} to 0, then set CF_{j (j=1 to n number of digits)} to each octaldecimal 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) Thanks again Gene for the challenge. It was fun to finally use NPV.
09222013, 05:18 PM
WP34S program. Seventeen steps. Executition time three ticks for any input.
# 099 // Scaling factor Some results:
Input Result True Delta This routine handles inputs from 1e99 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 1e16, 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.
Edited: 22 Sept 2013, 5:30 p.m.
09222013, 05:53 PM
Here are mine: WP34S:
09222013, 06:29 PM
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 WP34S, I wasn't familiar with the SDL, SDR, SKIP, and BACK instructions. My program produces correct results over the domain [0 to 7.777...]
09222013, 06:33 PM
My (nonwinning) RPL entry was:
148 bytes (not including a global name) 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.
09222013, 10:31 PM
My RPL entry was (didn't win, I got it down to 168.5 bytes)  HP 50g
<< 'N' STO 0 UNROT
09222013, 10:50 PM
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(.); Gerson.
09222013, 10:54 PM
Does this handle 1e50 ?  Pauli
09222013, 11:02 PM
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.
09232013, 02:56 AM
Although my stab at this uses 3 registers, it did come in at 15 steps on the WP34S. It handles values down to 1e99
CLREGS
09232013, 08:44 AM
Quote:
One more step can be save by replacing steps 001 and 002 with 01: ^{C}# 001
09232013, 11:51 AM
No numbered register was killed during the execution of this program, but down to 17 steps only: 001 ^{C}# 001
09232013, 12:16 PM
I played with a few line noniterated RPN approach which would use a built in octal to decimal conversion: My congradulations to the winners  and all who submitted entries!
09232013, 12:32 PM
That's what I have in my HP41C with the Advantage Module right now:
01 OCTIN Obviously 0 and 1 are not possible here. Gerson.
Edited: 23 Sept 2013, 12:33 p.m.
09232013, 07:32 PM
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.
09232013, 07:33 PM
The baton has passed. Others are exploiting the 34S function set better than I :) Congratulations to all, Pauli
09242013, 02:53 AM
You can have on HP41 (naked) and also on HP65 (but in 20 steps)
01 1E10 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
09242013, 02:59 AM
Thanks, it is as I thought.  Pauli
09242013, 07:48 AM
Quote:
Why? Rule #4 says:
I wasn't aware of that function, but DEC (octal to decimal conversion) is part of the HP41 instruction set. So, that should be ok, except for the 1 case. Likewise, the equivalent HP42S program should be ok too: 01 1E12
09242013, 08:01 AM
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 base8 log  which may cause such a problem: 8 ENTER 7 y^{x}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
09242013, 08:35 AM
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
09242013, 09:52 AM
Quote: 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: 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: Really fascinating, as nonconventional approaches usually are!
Quote: 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.
09242013, 10:25 AM
OCTIN allows for the input of integer octal constants. For instance: keystrokes display
However a better program (better if DEC were not natively available) would be: 01 OCTIN
Gerson. Edited: 24 Sept 2013, 10:25 a.m.
09242013, 12:27 PM
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) Or perhaps there is something I am not seeing? Forgive me if am mistaken. Miguel
09242013, 01:34 PM
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 HP42S. 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
Edited: 24 Sept 2013, 1:57 p.m.
09242013, 02:01 PM
Quote:Indeed. Everything works fine on my hardware 34s with v. 3.2 3405. Dieter
09242013, 02:03 PM
Hello Gerson, I am using V 3.2 3450. Physical device (not the emulator). Regards, Miguel
09242013, 02:13 PM
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
Edited: 24 Sept 2013, 3:07 p.m.
09242013, 03:40 PM
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
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.
09242013, 04:18 PM
Programs using DEC or >DEC aren't going to correctly deal with really small numbers in the [0, 1] interval. Try 1e50 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.
Edited: 24 Sept 2013, 4:19 p.m.
09242013, 04:20 PM
Hello Miguel
Quote: 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:
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.
09242013, 04:28 PM
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.
09242013, 05:20 PM
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.
09242013, 05:28 PM
For the record: this one is even one step shorter. 01: CPX CONST #001Yes, I like these 34s stack shuffle commands. :) Dieter
09242013, 06:28 PM
Quote: These can of course be replaced with
Quote:
QBASIC equivalent of the first program: DEFDBL AZ
09242013, 08:42 PM
Yes. I was confusing those two and confused myself :) Thank you Gerson. Regards, Miguel
09242013, 10:34 PM
Quote: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
09242013, 11:12 PM
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.
09242013, 11:50 PM
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.
09252013, 12:00 AM
Quote: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
09252013, 01:08 AM
HP15C version as of last Sunday:
001 g x=0
09252013, 01:21 AM
Quote: Me too, but they won't help here, it appears.
Gerson. 001 SDR 001 _{Edited to correct misspelling.}
Edited: 25 Sept 2013, 2:41 p.m. after one or more responses were posted
09252013, 01:48 AM
This piece of code almost makes me wish I'd implemented the integer mode shifts in real mode too :)  Pauli
09252013, 02:45 PM
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.
09252013, 03:08 PM
Hello,
Here is some HP Prime code for both contests. note: replace SigmaList byt he appropriate symbol
export RplProgContest(Base, X, Y) note, you can replace the {1,10..} by makelist(10^A,A,0,11), smaller, but slower
export RpnProgContest(X) Cyrille
09252013, 05:43 PM
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.
09252013, 06:08 PM
From my integer base conversion routine circa 1984, so some optimization is possible.
001 f LBL B ; define base 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 HP16C :)
Edited: 25 Sept 2013, 6:12 p.m.
09262013, 08:19 AM
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 everydayprogramming. So please forgive me if I dig out this idea once again. Dieter
09262013, 11:39 PM
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 carryfree 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. :( «
09302013, 10:58 PM
That's a heck of a single line of code Cyrille! :) How are the renovations going? Geoff
10012013, 12:27 AM
Quote: Reminds me this can be done on the HP17BII 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. 
« Next Oldest  Next Newest »
