WP 34S mini-challenge

[walter b]

I can confirm those discussions

[walter b]

(01-21-2014 12:22 PM)Didier Lachieze Wrote:  So, what about this one:

Code:

01 LBL A
02 x²
03 STO+ L
04 CLx
05 #1/2
06 RCL* L
07 RTN

Looks great!

d:-)

[Gerson W. Barbosa]

(01-21-2014 11:55 AM)Paul Dale Wrote:  

(01-21-2014 08:26 AM)Didier Lachieze Wrote:  Here is my solution:
...

This solution does disturb the stack. If Y contains 2.3, it will end up containing after the switch to integer mode and back. Still, a very good try.


- Pauli

Isn't this something that should be addressed, or is there a technical reason that makes it difficult to preserve the original float number after switching back from an integer mode? On the HP-42S, for instance, BASE BIN will convert 2.3 to 10., as expected and a subsequent DEC will restore it to 2.3 again. Shouldn't this be the expected behavior? Thanks!

Gerson.

[walter b]

(01-21-2014 01:06 PM)Gerson W. Barbosa Wrote:  

(01-21-2014 11:55 AM)Paul Dale Wrote:  This solution does disturb the stack. If Y contains 2.3, it will end up containing 2.0 after the switch to integer mode and back.

Isn't this something that should be addressed, or is there a technical reason that makes it difficult to preserve the original float number after switching back from an integer mode? On the HP-42S, for instance, BASE BIN will convert 2.3 to 10., as expected and a subsequent DEC will restore it to 2.3 again. Shouldn't this be the expected behavior? Thanks!

There is nothing like data types in the WP 34S. AFAIK, some of the nicer features of the HP-42S rely on such data typing.

d:-/

[Sanjeev Visvanatha]

Four steps, y'all:

LBL D
RCL+ 01
IP
DSE 01
GTO D
RTN

This assumes you enter the following keystrokes to solve the problem
100000.00001 STO 01
CLx
D

This takes time though!

(please excuse if I overlooked the stack lift, but I think it preserves the stack)[/code]

[Gerson W. Barbosa]

(01-21-2014 01:56 PM)Sanjeev Visvanatha Wrote:  Four steps, y'all:

LBL D
RCL+ 01
IP
DSE 01
GTO D
RTN

This assumes you enter the following keystrokes to solve the problem
100000.00001 STO 01
CLx
D

This takes time though!

(please excuse if I overlooked the stack lift, but I think it preserves the stack)[/code]

The original HP-15C program assumes n on register X, no previous initialization:

100000 GSB A --> 5000050000

Anyway, your program would return 5000150000, which is off by 100000. But of course it can be improved. Since the increment is 1 the fractional part is optional, thus saving the IP instruction. Also, you can use BACK nnn to save occasional LBLs steps in the middle of the program.

Regards,

Gerson.

[Gerson W. Barbosa]

(01-21-2014 11:29 AM)Paul Dale Wrote:  I considered an integer mode solution too. The shortest I could come up with is:

Code:

        x²
        RCL+ L
        SR 01

Which is three steps. However, I figured decimal mode was wanted and proposed the alternative above which works for non-integer inputs. Sadly, I had an extra hour to think about this problem on my drive home today after an accident on the freeway

I wouldn't be at all surprised if a four (or less) step solution was possible. The 34S has an (almost) insane number of functions and people on this forum are better at utilising the calculator than I. I consider this a good thing, of course


- Pauli

In principle the mini-challenge is interested only in integer results ("It computes the sum of the first n natural numbers using Gauss's formula."). Of course if it gives valid results for real inputs, as does my original solution, yours and Didier's, so much the better. It is required that the calculator modes get back to the default settings (like DECM) when done, in case they're changed by the program. This would make for five steps (additional BASE 02 and DECM instructions), if DECM restored the original float numbers when switching back from BASE 02, of course.
If we are pleased with integer arguments only, then even an HP-42S is almost possible:

Code:


00 {14-Byte Prgm}
01 LBL "GS"
02 X^2
03 RCL+ ST L
04 ??                  ;  these are not the exclusive WP 34 instructions
05 ??                  ;  I've used, but would be kind of a spoiler to the
06 ??                  ;  original solution in case they were disclosed
07 END

100000 XEQ GS --> 5000050000

but

50000 XEQ GS --> 1250024999 (too bad this error of 1 unit due to rounding error)

Cheers,

Gerson.

[Didier Lachieze]

(01-21-2014 03:44 PM)Gerson W. Barbosa Wrote:  If we are pleased with integer arguments only, then even an HP-42S is almost possible:

Code:

00 {14-Byte Prgm}
01 LBL "GS"
02 X^2
03 RCL+ ST L
04 ??                  ;  these are not the exclusive WP 34 instructions
05 ??                  ;  I've used, but would be kind of a spoiler to the
06 ??                  ;  original solution in case they were disclosed
07 END

100000 XEQ GS --> 5000050000

but

50000 XEQ GS --> 1250024999 (too bad this error of 1 unit due to rounding error)

Cheers,

Gerson.

Well, here is a solution working on both the 42S and WP 34S, not limited to integers and where I don't see the rounding error highlighted above:

Code:

00 {15-Byte Prgm}
01 LBL "GS"
02 X^2
03 RCL+ ST L
04 1/X
05 RCL+ ST X
06 1/X
07 END

100000 XEQ GS --> 5.000.050.000
50000 XEQ GS --> 1.250.025.000

[Sanjeev Visvanatha]

(01-21-2014 02:19 PM)Gerson W. Barbosa Wrote:  The original HP-15C program assumes n on register X, no previous initialization:

100000 GSB A --> 5000050000

Anyway, your program would return 5000150000, which is off by 100000. But of course it can be improved. Since the increment is 1 the fractional part is optional, thus saving the IP instruction. Also, you can use BACK nnn to save occasional LBLs steps in the middle of the program.

Regards,

Gerson.

Thank you. Revisions are respectfully submitted below, for a 5 step solution:

LBL D
X-><- 01
CLx
RCL+ 01
DSE 01
BACK 002
RTN

I believe this leaves the stack unchanged as well, but does take a while with your example.

100000 D ----> 5,000,050,000

[Gerson W. Barbosa]

(01-21-2014 04:29 PM)Sanjeev Visvanatha Wrote:  Thank you. Revisions are respectfully submitted below, for a 5 step solution:

LBL D
X-><- 01
CLx
RCL+ 01
DSE 01
BACK 002
RTN

I believe this leaves the stack unchanged as well, but does take a while with your example.

100000 D ----> 5,000,050,000

You're quite welcome! All solutions are welcome, even if not the expected ones. Also you've come up with a better solution than the one in my reply to Walter, thus perfectly fitting into the required 5-step limit. Oh, and it surely leaves the stack unchanged after program execution.

Thanks for your contribution and interest!

Regards,

Gerson.

[Sanjeev Visvanatha]

I submitted my initial solution without looking at what was submitted at that point in time. So, I did not see the other similar solution until I received your first reply! I got to know my wp-34s better, so thanks go to you for giving me the impetus to do so!

[Gerson W. Barbosa]

(01-21-2014 04:07 PM)Didier Lachieze Wrote:  

(01-21-2014 03:44 PM)Gerson W. Barbosa Wrote:  If we are pleased with integer arguments only, then even an HP-42S is almost possible:

Code:

00 {14-Byte Prgm}
01 LBL "GS"
02 X^2
03 RCL+ ST L
04 ??                  ;  these are not the exclusive WP 34 instructions
05 ??                  ;  I've used, but would be kind of a spoiler to the
06 ??                  ;  original solution in case they were disclosed
07 END

100000 XEQ GS --> 5000050000

but

50000 XEQ GS --> 1250024999 (too bad this error of 1 unit due to rounding error)

Cheers,

Gerson.

Well, here is a solution working on both the 42S and WP 34S, not limited to integers and where I don't see the rounding error highlighted above:

Code:

00 {15-Byte Prgm}
01 LBL "GS"
02 X^2
03 RCL+ ST L
04 1/X
05 RCL+ ST X
06 1/X
07 END

100000 XEQ GS --> 5.000.050.000
50000 XEQ GS --> 1.250.025.000

Very nice! More accurate and faster than mine, but that was the goal of the mini-challenge: to increase our arsenal of solutions for further use.

Well, at least my WP 34S program returns 1.250.025.000,000003 for that particular example, which is quite acceptable for a finite-precision machine. I will post it later.

Regards,

Gerson.

[Dieter]

(01-21-2014 11:48 AM)Paul Dale Wrote:  The divide by two is what is stumping me. x² RCL+L 2 ÷ is the obvious solution but it doesn't preserve the stack and saving the stack consumes more steps than are available.
...
Likewise my proposal to include arithmetic operators with a small constant argument was vetoed, otherwise the space & stack saving ÷2 instruction would have been available.

What? Who vetoed against this? Some time ago I suggested a simple instruction that might have been called HALF or something similar. If possible it should take a register address, so that here a HALF X would have done the trick. The main reason why it did not get implemented was the lack of available memory. Now I hear that such an instruction would have been possible. ?!?

Dieter

[Paul Dale]

Walter vetoed it of course

Most things are possible, weather they justify themselves is the important thing. These instructions didn't.


I proposed a set of instructions:

Code:

+ nnn
- nnn
[times] nnn
[divide] nnn

Which performed the specified operation to X using the associated constant. Thus, "- 22" would subtract 22 from X (doing the right thing with Last X).


- Pauli

[nsg]

And here is another way to divide by 2 without touching stack:

Code:

01 LBL A
02 X^2
03 RCL+ L
04 LB
05 DEC X
06 2^X
07 END

There is a middle ground. Use constants 1-4 only. this way only 4 bits (2 fror constant and 2 for operation) represent variation and therefore only 16 opcodes are wasted.
And constants 1-4 cover easily 99% of cases.

(01-21-2014 10:13 PM)Paul Dale Wrote:  I proposed a set of instructions:

Code:

+ nnn
- nnn
[times] nnn
[divide] nnn

Which performed the specified operation to X using the associated constant. Thus, "- 22" would subtract 22 from X (doing the right thing with Last X).

[Gerson W. Barbosa]

(01-21-2014 10:46 PM)nsg Wrote:  And here is another way to divide by 2 without touching stack:

Code:

01 LBL A
02 X^2
03 RCL+ L
04 LB
05 DEC X
06 2^X
07 END

This exactly matches mine! I knew it would appear sooner or later :-)

Code:


001 LBL A
002 x²
003 RCL+ L
004 LOG₂
005 DEC X
006 2ˣ
007 END

Perhaps there are other ways around, some of which might even work on other RPN calculators, like Didier's.
Thank you all for your interest and contributions.

Gerson.

Edited to fix subscript and superscript characters

[Gerson W. Barbosa]

And here is my rather flawed HP-42S solution:

Code:


00 {14-Byte Prgm}
01 LBL "GS"
02 X^2
03 RCL+ ST L
04 LN                 
05 COSH               
06 IP                  
07 END

Only for integer arguments. It might return results off by one unit, for some (not so) large arguments.

[Sanjeev Visvanatha]

(01-21-2014 11:48 AM)Paul Dale Wrote:  ...
Even using the statistical Σ+ command doesn't seem to help.
...

It works using Σ+ so long as the summation registers are clear:

LBL D
Σ+
X<>L
X^2
Σ+
x̄
RTN

I believe the stack remains 'unchanged'. However, the Y register is altered (I believe) through the use of the mean command. In this case though, original Y is returned back to Y. Due to the requirement that the summation registers are cleared prior to execution, the criteria of the challenge were not met.

[walter b]

(01-21-2014 10:13 PM)Paul Dale Wrote:  Most things are possible, weather they justify themselves is the important thing. These instructions didn't.

So true.

(01-21-2014 10:13 PM)Paul Dale Wrote:  I proposed a set of instructions: ...
Which performed the specified operation to X using the associated constant. Thus, "- 22" would subtract 22 from X (doing the right thing with Last X).

IIRC, such discussions occurred when we were approaching asymptotically the first release of a SW for our (then still potential) users. At that time, I had faithfully added each and every arcane function to the documentation so far and was simply fed up with it. Maybe I even pointed to the function sets of vintage calcs which were able to solve everything nevertheless. As I said, IIRC.

d;-)

BTW, before voting for more instructions how about using the right reply button in this very forum? This would demonstrate maturity for an extended instruction set

[Thomas Klemm]

There's a left reply button?