(15C) Decoder for HP 15c programs

[pinkman]

Hi everyone,
as a newbie on '15C, I still need a decoder to understand what I wanted to do in my programs, when I read them after a few days...

I've not really searched on the web, but I created a small Excel decoder that you could download and/or improve. I'm not an Excel fan, but I'm sure it can be opened in any other sheet tool, as there are only a few formulas and a lot of copy-paste stuff.

[There are still some stupidities such as "LBL e^x" instead of "LBL B", or "DSE TAN" instead of "DSE I", but it already really improves readability.]
EDIT [15/03/18]: improved decoding for stupid things seen above. Now you got "RCL (I)" or "LBL C"...
EDIT [22/03/18]: new version attached, see messages below

cu

[pinkman]

Attached picture: small sample with the memory game posted on this site.

How to use?
Write the instructions you read on the 15C in the yellow cells, line after line, then read the result in the white cells.
   

[Dieter]

(03-16-2018 07:16 AM)pinkman Wrote:  Attached picture: small sample with the memory game posted on this site.

Very nice, thank you very much.
May I add three suggestions?

1. Among others, Unicode supports the following characters:
± × ÷ ≠ ≤ ≥ ∞ ∫ √ ← ↑ → ↓ ↔ π σ Δ Σ
So you do not have to resort to ASCII transscriptions for the Integrate function, the comparison tests, or for arrows in conversions, and Δ% or Σ+ do not have to be written as %CH or E+. Maybe the superscript-2 for x² can be accessed directly from your keyboard (over here it's AltGr+2). You may even use an overscore or macron with a superscript-1 to get sinˉ¹. The only problematic cases are x-bar and y-hat.

2. A major part of the world uses a decimal comma. Maybe you should add one line in the REF sheet. ;-)

3. Not everyone uses a current Excel version. So I'd suggest a more common file format like Excel 2000/XP *.xls instead of the newer XML-based *.xlsx.

Dieter

[pinkman]

Thanks for these suggestions.
I'm always afraid using special characters in MS generated files, feeling suspicious on how they will deal with Unicode.

I'll improve the small tool with your ideas, I also have to check if I am error proof with labels of the form "LBL .x".

[rprosperi]

(03-16-2018 08:51 AM)Dieter Wrote:  2. A major part of the world uses a decimal comma. Maybe you should add one line in the REF sheet. ;-)

While there's no question that a decimal comma should be supported, is it really correct that "a major part of the world" uses it? How large is major? No pejorative implied, I simply didn't think that was the case. Alternately, I'd say "an important part of the world" does when discussing mathematics, and in any case, a significant part of the audience here.

[Dieter]

(03-18-2018 12:34 AM)rprosperi Wrote:  

(03-16-2018 08:51 AM)Dieter Wrote:  2. A major part of the world uses a decimal comma. Maybe you should add one line in the REF sheet. ;-)

While there's no question that a decimal comma should be supported, is it really correct that "a major part of the world" uses it? How large is major?

Large enough to be significant. ;-) I didn't want to say it's the majority, but a significant part, as you put it.

But take a look at the world map in the Wikipedia article on decimal separators. I would say the green part of the map qualifies for "a major part".

Dieter

[SlideRule]

(03-18-2018 08:37 AM)Dieter Wrote:  … in the Wikipedia article on decimal separators…

Hmm.. something about RADIX there also..

"In mathematics the decimal separator is a type of radix point, a term that also applies to number systems with bases other than ten".

some excellent source references on math notation …

Number Theory via Notation
Numerical Notation a comparative history
a History of Mathematical Notations I
a History of Mathematical Notations II
Notations in Elementary Mathematics vol I
Notations in Elementary Mathematics vol II

BEST!
SlideRule

[rprosperi]

(03-18-2018 08:37 AM)Dieter Wrote:  But take a look at the world map in the Wikipedia article on decimal separators. I would say the green part of the map qualifies for "a major part".

Thanks Dieter, a very interesting, revealing and eye-opening graphic. By land-mass, I guess comma-separator countries are indeed the majority, though by population, clearly not.

Other observations:

1. It is surprising how much area (how many countries) there is no data for (though I sure don't know about any of them either)

2. I know many people all over Canada (including family) and none of them use commas. Most I know are in Quebec, presumably the province most likely inclined to use European standards. Comments Canadians?

3. I had no idea Russia and the former USSR members used commas.

Again, thanks for sharing this.

[pinkman]

New version attached:
- fixed the lack of .0 to .9 decoding
- used the unicode chars given by Dieter, except for the square root (SQRT) and the standard deviation (SDEV) to increase readability
- given the same privileges to comma and decimal point, whatever the above discussion may have conclude or not (I'm in a "comma zone" but with computers I prefer using the decimal point to avoid confusion in source code)

[Dieter]

(03-22-2018 05:11 PM)pinkman Wrote:  New version attached:
- fixed the lack of .0 to .9 decoding
- used the unicode chars given by Dieter, except for the square root (SQRT) and the standard deviation (SDEV) to increase readability
- given the same privileges to comma and decimal point, whatever the above discussion may have conclude or not (I'm in a "comma zone" but with computers I prefer using the decimal point to avoid confusion in source code)

Thank you very much. Unlike the other test commands, X=0? and X≤Y? have no question marks, so I added them in my copy. ;-)

There is one thing I cannot check here: If you enter a code like 44 .1 (=STO .1), this works fine here with an Excel version localized for a decimal comma: the ".1" is not recognised as a number and interpreted as text which is correctly translated. But does this also work in regions with a decimal point? If I enter 44 ,1 the ,1 is interpreted as the number "0,1" and thus the lookup does not work. Maybe formatting the cells as "Text" would solve this.

BTW, would you consider it a good idea to complement the ten non-keyboard tests with the respective TEST # so that the listing would show e.g. X>0? (TEST 1) ?

Dieter

[pinkman]

Thanks again for your suggestions, answers hereafter.

(03-22-2018 06:36 PM)Dieter Wrote:  Thank you very much. Unlike the other test commands, X=0? and X≤Y? have no question marks, so I added them in my copy. ;-)

Good point, and see my proposal below.

(03-22-2018 06:36 PM)Dieter Wrote:  There is one thing I cannot check here: If you enter a code like 44 .1 (=STO .1), this works fine here with an Excel version localized for a decimal comma: the ".1" is not recognised as a number and interpreted as text which is correctly translated. But does this also work in regions with a decimal point? If I enter 44 ,1 the ,1 is interpreted as the number "0,1" and thus the lookup does not work. Maybe formatting the cells as "Text" would solve this.

Well it has been a problem for me, as Excel does not strictly handle Text formats as needed, always suggesting to correct the format to a number value. Also, apparently the search function I'm using to find the values in the REF list does not work with forced text cells, so the decoder is inoperant.
I could not find any solutions, so I rolled back to a previous version, assuming people will use the entries that work for them, eventually with modifications of the REF lists. My apologies for that.

(03-22-2018 06:36 PM)Dieter Wrote:  BTW, would you consider it a good idea to complement the ten non-keyboard tests with the respective TEST # so that the listing would show e.g. X>0? (TEST 1) ?

Dieter

Yes for sure!!! And I can extend my answer to your first question. I generalize the translation you propose for tests with 2 parts: <readable form> (<keyboard form>).

X=0? becomes X=0? (X=0)
and therefore:
X≤Y? (X≤Y)
X=Y? (TEST 5)
X≠Y? (TEST 6)
...

[Dieter]

(03-30-2018 05:22 PM)pinkman Wrote:  Well it has been a problem for me, as Excel does not strictly handle Text formats as needed, always suggesting to correct the format to a number value. Also, apparently the search function I'm using to find the values in the REF list does not work with forced text cells, so the decoder is inoperant.

Yes, I know that the lookup functions can be a PITA. But there is a solution – you just have to be smarter than Excel. ;-)

The safest way here is: first format all respective cells als text. Then fill these cells after (!) the formatting. You can also reenter them by pressing F2 (edit) and ENTER. Finally you have to make sure that the tests for instance do not compare a cell with 42 (number) but with "42" (text). Or you may use VALUE() to compare the value of a cell with the numbers 42 and 43.

Based on your second version, I also added ten more for entries ",0" to ",9" to the REF sheet, and now it works as I think it should. But more important: column F and G in REF translate LBL SQRT into LBL A, but the respective GTOs and GSBs are missing. So I addded ten entries for GTO SQRT ... GTO 1/x and GSB SQRT ... GSB 1/x.

(03-30-2018 05:22 PM)pinkman Wrote:  

(03-22-2018 06:36 PM)Dieter Wrote:  BTW, would you consider it a good idea to complement the ten non-keyboard tests with the respective TEST # so that the listing would show e.g. X>0? (TEST 1) ?

Yes for sure!!! And I can extend my answer to your first question. I generalize the translation you propose for tests with 2 parts: <readable form> (<keyboard form>).

Great. Thank you very much.

Dieter