(15C) another approach to decimal <> binary conversion

11292017, 10:32 AM
(This post was last modified: 11292017 04:31 PM by jthole.)
Post: #1




(15C) another approach to decimal <> binary conversion
This is my first try at creating a useful RPN program, so any comments for improvement are welcome!
A well known strategy for representing a decimal number in binary notation, is to keep dividing by two, and placing a "1" if the fractional part > 0, and a "0" if the fraction is 0. At the end of the conversion, the binary result is the output read backwards. That works well for uneven numbers, but you will lose zeros for even numbers. I've written my own conversion (not using an existing program as the basis, so I surely have made beginner mistakes), which prefixes the number with a "8". That makes sure the leading zeros are preserved, and can be easily read as "B" for binary ;) This program takes 20 steps, and uses storage register 0 for intermediate results. Since I am still waiting for the DM15L to arrive, I tested this in the following HP 15C emulators:  Touch 15C on Android  The online hp15c.com emulator Code: 001 8 To start the program, input the decimal number you want to convert (no need to press enter), and press R/S. The binary number is returned in the X register (in reverse). Here's the same program for the HP 12C: Code: 01 8 

11302017, 07:50 PM
Post: #2




RE: (15C) another approach to decimal <> binary conversion
(11292017 10:32 AM)jthole Wrote: I've written my own conversion (not using an existing program as the basis, so I surely have made beginner mistakes), which prefixes the number with a "8". That makes sure the leading zeros are preserved, and can be easily read as "B" for binary ;) Ah, that's what the "8" is for. #) (11292017 10:32 AM)jthole Wrote: To start the program, input the decimal number you want to convert (no need to press enter), and press R/S. If the program happens to be set to step 000 or 001, that is. The five keys A...E on the 15C are there to avoid exactly this problem. Press f[A] and the program starts at LBL A. Or B, C, D or E, respectively. That's what these keys are for. In user mode you don't even have to press the [f] prefix. So you should not waste these useful labels A...E for simple loops or the like. Have you program start with LBL A and replace the existing LBL A with, say LBL 0 or LBL 1 or another numeric label. (11292017 10:32 AM)jthole Wrote: The binary number is returned in the X register (in reverse). Not if you turn the calculator upside down. This was even the "b" becomes a suffix that makes sense: 81111000 then can be read as 0001111B. :) And finally... what about a version that returns a result in the correct order ?) Dieter 

12012017, 08:48 AM
Post: #3




RE: (15C) another approach to decimal <> binary conversion
(11302017 07:50 PM)Dieter Wrote: And finally... what about a version that returns a result in the correct order ?)Thanks for your comments, especially about label use; I clearly can learn something there (and in many other areas). I do have the algorithm for computing the result in the right order on paper (maybe not the most efficient one, using the fact that 10^int(2log(n)) puts the "1 in the right place") but real life is interfering right now, so I'll have to code (and improve) that at a later time. I am sure there are more efficient algorithms, and also programs for "base n to base m" conversions. So if this was a real world problem, I would do some literature search first. But the learning experience is fun 

09012018, 06:16 PM
Post: #4




RE: (15C) another approach to decimal <> binary conversion
I've taken this generic base conversion program and hardcoded frombase=10 and tobase=2:
Code: 001  44 0 STO 0 Example f CLEAR PRGM 47 R/S 101,111.0000 And here's the program for the HP12C: Code: 01  44 0 STO 0 (11302017 07:50 PM)Dieter Wrote: Ah, that's what the "8" is for. #) It has a different meaning in my program and is actually needed. 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)