![]() |
HHC 2013 RPN Programming Challenge - Final Thought - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: HHC 2013 RPN Programming Challenge - Final Thought (/thread-253024.html) |
HHC 2013 RPN Programming Challenge - Final Thought - Jeff O. - 10-16-2013 In case anyone wants a diversion from the Prime discussion, I had one final thought about the HHC 2013 RPN Programming Challenge that I’ve been meaning to bring up. (I’m probably the only person who spent much time on the challenge after about September 25, but I enjoy them and so tend to keep fiddling with them long after the conference.) I don’t have any new programming revelations or insights beyond what the group presented in the few days after conference, just this: I believe all of the solutions presented at the forum (except Pauli’s here) converted the octal value one digit at a time, from left to right. At some point, I began to wonder if it would be more accurate to convert the number from right to left, i.e., start with least significant digit. It seemed to me that conversion from right to left would more accurately get the carry correct from the far right digits. Perhaps that is not a real concern, but I decided to attempt to write a program to do so, probably just for the fun of it. While I was able to write a 15 step wp34s program to convert from left to right, the best I have done so far for right-to-left conversion is 27 steps, as follows: Step Command Comment The above is for a 12-digit entry, since that’s the most you can enter on a wp34s. If you enter a value with less than 12 digits, it dutifully converts the trailing zeroes. Although I did not intend this result, this program seems to work for any value that can be entered into a wp34s, i.e., is not limited to 0 <= n <= 1. It does of course assume a valid octal input, i.e. no 8s or 9s.
I note that this program does produce what Pauli declares to be the “True” answer for an input of 1e-95, so perhaps it is more accurate?
My solution for the HP 65 ! Re: HHC 2013 RPN Programming Challenge - Final Thought - Gene Wright - 10-16-2013 Here it is. Works.
LBL
Please feel free to improve upon this. :-)
Re: My solution for the HP 65 ! Re: HHC 2013 RPN Programming Challenge - Final Thought - Geoff Quickfall - 10-16-2013 Which 65 did you use :-)
Re: HHC 2013 RPN Programming Challenge - Final Thought - Paul Dale - 10-16-2013 My solution was digit at a time right to left, albeit with some limitations on the number of decimal places and the maximum value.
- Pauli
Re: HHC 2013 RPN Programming Challenge - Final Thought - Jeff O. - 10-17-2013 After I developed my right-to-left conversion program, I thought I’d better re-check the solutions presented here before I asserted that they were all left-to-right. (I admit to not having studied them all in detail on first reading.) Your program looked similar to others that did it left-to-right, but then I noticed the MOD instruction and deduced you were doing it right-to-left.
Regarding your use of MOD, I decided to try that instead of my method using FP to strip off one digit right of the decimal and then multiplying by 10. Doing so required me to use a (local) storage register, but I was also able to make it one step shorter, down to 26: 001 ENTER duplicate entered value
Of course if I use a local storage register in my original version, I also save a step. The local register starts at zero, and so eliminates the need to enter a zero, which then saves a stack manipulation step later: 001 ENTER duplicate entered value Assuming I understand it correctly, I like your method of adding a digit, then dividing by 8 to push the result one octal digit. Eliminates the need to raise 8 to some power and keep a running multiple of 8. I think I’ll see if I can work that into my method to handle all 12 digit inputs.
Improved version, using Pauli's method to convert the mantissa from right to left, then shift that left or right as needed based on the exponent by raising 8 to the appropriate power: 1 LocR 002 create two local registers
Last and maybe least, the following version converts the maintissa rigth to left, then shifts the result left or right as required by repeatedly multiplying by 8 or 1/8. The thought is that repeated multiplication may be more accurate than raising 8 to some power. 11 LocR 002 create two local registers
edit 1 - changed MOD to RMDR in first program to make it work with negative inputs.
Edited: 23 Oct 2013, 8:46 a.m.
Re: My solution for the HP 65 ! Re: HHC 2013 RPN Programming Challenge - Final Thought - Jeff O. - 10-17-2013 Hi Gene, Re: My solution for the HP 65 ! Re: HHC 2013 RPN Programming Challenge - Final Thought - Gene Wright - 10-17-2013 doh!
Correct!
Re: My solution for the HP 65 ! Re: HHC 2013 RPN Programming Challenge - Final Thought - Jeff O. - 10-17-2013 In that case, it works great!* At least as implemented in this wp34s program that only collapses the HP-65 two-step instructions for things like LBL A and RCL 3 into single step equivalents, but does not take advantage of any other wp34s improvements: Step Command Comment
* - well, works great with some input limitations that don't quite meet the 0 <= n <= 1 range specified by the Master of the Challenge :-)
|