▼
Posts: 614
Threads: 66
Joined: Jul 2006
Hi Valentin,
I feel I must gently chastise you a little bit  hopefully in good humor. :)
When I initially read your description of the challenge and the rules you laid down I thought I'd get to see another one of your well thought out and documented RPN calculator solutions. Something similar to your Datafile articles. Your rules stated:
"Giving *just* the solutions (but no program) or providing programs for machines other than (preferably HP) *calculators* is to be considered as blatant disrespect to the stated rules and/or a clear statement of utter inability to comply within these terms."
The word calculator was underlined to stress that you were looking for calculator solutions. You then proceeded to state:
"Two or three days from now I'll post my solution (plus comments), which is essentially a rather simple, unoptimized 4line program (plus variations) for a barebones HP71B that takes less than 2 minutes to find the only solution..."
I realize that you view the HP71B as a "calculator" but I would view it more as a "computer" since it uses Basic. I could easily use Basic on my PC and then translate it to the HP71B or one of the Sharp versions of Basic. But wouldn't you say that would defeat the purpose of a HP "calculator" challenge.
Please take my comments as a gentle nudge  I always enjoy seeing your HP71B solutions, BUT I much more enjoy the RPN solutions. Fortunately there was one RPN solution but it would have been great to see yours also.
I'm afraid I didn't have much luck with this particular challenge, but enjoyed it anyway. I'm looking forward to trying my luck with your next challenge.
Bill
12345
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Bill:
Bill posted:
"I feel I must gently chastise you a little bit  hopefully in good humor. :)"
Be my guest, let's see ...
"When I initially read your description of the challenge and the rules you laid down I thought I'd get to see another one of your well thought out and documented RPN
calculator solutions [...] The word calculator was underlined to stress that you were looking for calculator solutions."
That's correct.
"I realize that you view the HP71B as a "calculator" but I would view it more as a "computer" since it uses Basic."
Yes, it's the same old problem discussed many times before of the exact definition of "calculator" vs. "computer". The extreme cases are obvious, but there's a certain blurred line where you can't assign a clear classification. For some, the HP71B is a computer, while the HP41C is a calculator. Yet both are the central unit of complete systems, do have CPU, display, RAM, ROM, peripherals, system extensions, you name it. Why should one be considered a "calculator" and the other a "computer" ? No reason at all. Even HP themselves called the 41C a "computer" in a lot of marketing adds and materials.
Of course, I could clarify by giving a large list of allowed machines, but that's nonsensical. We all know what kind of machines we're talking about. An HP25 ? Yes. HP41C ? Yes. HP71B ? Yes. HP48/49 (much more powerful than the 71B) ? Yes. SHARP PC1211 ? Yes. TI59 ? Yes.
A Pentiumbased PC compatible ? No. Some mainframe ? No. An ancient Apple II running BASIC ? No. A Sinclair ZX Spectrum ? No. Some PDA ? No. I hope you get the point.
"I could easily use Basic on my PC and then
translate it to the HP71B or one of the Sharp versions of Basic."
By all means do. And don't forget to post the resulting program.
"But wouldn't you say that would defeat the purpose of a HP "calculator" challenge."
No. As long as the resulting program runs in one of 'approved' models, be it an HP41, HP71, or HP48, say, I don't mind how it came into existence, be it as a translation from a Cray1 program, or because you channeled some alien in Omicron Persei 8.
"Please take my comments as a gentle nudge  I always enjoy seeing your HP71B solutions, BUT I much more enjoy the RPN solutions."
Then submit one yourself, so that everyone can see how it's done.
"Fortunately there was one
RPN solution but it would have been great to see yours also."
Thanks a lot for your interest and kind words, but giving MY solutions for the HP71B instead of for some RPN (or RPL) model has a number of important advantages, among them:
 Everyone can try out a solution for the HP71B, as there is a perfect emulator, Emu71, which everyone can download and use for free, to test my solutions, or to develop their owns. Should I give a solution for other machines, there may or may not exist a free emulator (including free ROMs) for that machine, or people may not have that physical model.
 HP71B's BASIC is powerful enough that a solution can be given in a (very) few lines, and being BASIC, it's easy to understand the code, and thus easy to translate to other calculator languages. An RPN solution would typically required a hundred steps or more, and it's much more cryptic and difficult to understand, let alone translate it to run in other machines, even if RPN.
 It's very easy for me to copypaste the program listing and results from Emu71. Doing it from a physical machine or other emulators would be a lot more work and error prone, and designing these challenges and creating the solutions already requires more free time that I can reasonable allocate to this, so the less unnecessary work involved, the better.
... and there are more reasons, but I think these three make my point clear.
"I'm afraid I didn't have much luck with this particular challenge, but enjoyed it anyway. I'm looking forward to trying my luck with your next challenge."
... and I'm looking forward for your next contribution, be it an RPN program or some IBM PC Basic program you translated to HP71B BASIC (or RPL, for that matter). And of course, submitting an untranslated program would be utterly unacceptable. :)
Thanks a lot for your interest and comments, and
Best regards from V.
▼
Posts: 123
Threads: 7
Joined: Jan 1970
>Of course, I could clarify by giving a large list of allowed machines, but that's nonsensical. We all know what kind of machines we're talking about. An HP25 ? Yes. HP41C ? Yes. HP71B ? Yes. HP48/49 (much more powerful than the 71B) ? Yes. SHARP PC1211 ? Yes. TI59 ? Yes.
<>
A Pentiumbased PC compatible ? No. <> Some PDA ? No. I hope you get the point.
===
But what is the difference? You can write a program in a PC systems language, and very easily recompile it for a Texas or a 49 with minimal changes. Aside from the smaller RAM and slower CPU (not really an issue in most of the challenges) the program will execute identically on both.
Suppose I developed and debugged my program in a PC, and then simply recompiled it for a HP49 (maybe ten mins work). Does that qualify as a valid solution? Is so, where is the challenge? It is far less work for me than for someone using an ancient HP.
Modern calculators are just PDAs anyway, with less RAM and a different UI.
.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, . :
. posted:
"You can write a program in a PC systems language, and very easily recompile it for a Texas or a 49 with minimal changes. Aside from the smaller RAM and slower CPU (not really an issue in most of the challenges) the program will execute identically on both."
I think my answer to Bill was clear enough: as long as you post a solution that will run in some HP calc model (or even some suitably ancient SHARP or other brands), I don't care how you managed to create it. You want to do it as it is intended, by writing a program directly for a physical HP calc using a physical HP calc ? Good. You want to do it in a roundabout way by first writing it in, say, Java, on a laptop, then translating that Java code to RPN ? Equally good, you'll probably enjoy doing it and learn something in the process.
As long as you then post a solution in RPN, RPL, 71B BASIC, ancient SHARP handhelds BASIC, TI's AOS, or any other language for any other model according to the examples I gave, I don't mind. It's the end result that matters to me, not how you got there.
Myself, I originally write the solutions in HP71B BASIC using Emu71, for the reasons given in my answer to Bill. If the challenge is for the HP15C, I might use either a real 15C or an emulator, but I´ll post something that *runs* on a *physical* HP15C, even if I designed and tested the original algorithm in Java, say.
Mind you, translating that Java code to 15C's RPN would be a major programming feat in itself, don't you think ?
"It is far less work for me than for someone using an ancient HP."
Good for you. Go ahead full steam and please, post your results.
"Modern calculators are just PDAs anyway, with less RAM and a different UI."
That's an opinion, not necessarily a fact. I'm not very interested in modern calculators. This is the "Museum of HP"'s Forum, so ancient models should be the primary focus, you can always use comp.sys.hp48 for modern models. My challenges are thus primarily intended for ancient models, though I'm pretty happy to get solutions for modern machines such as the 48/49, if only for comparison purposes. I also try to delve in curious or otherwise interesting mathematical facts as well.
Anyway, as long as people enjoy the challenges and, ideally, learn something or find something useful, my goal is met. I don't really care for strict rules, limits or exclusions, but I think that giving a Java solution with timings acquired on a Pentium IV at 3.2 Ghz for a 4line challenge intended for ancient calculators is simply missing the mark by a parsec or so.
Thanks for you interest and comments, and
Best regards from V.
Edited: 23 May 2005, 11:02 a.m.
▼
Posts: 123
Threads: 7
Joined: Jan 1970
>You want to do it in a roundabout way by first writing it in, say, Java, on a laptop, then translating that Java code to RPN ? Equally good, you'll probably enjoy doing it and learn something in the process.
My point is you don't need to translate. These days the same languages work perfectly fine on both PCs and calculators. It is almost trivial to port code from one to the other.
Whats the command to print 'Hello World' on a TI89?
printf("Hello World");
What about on a casio?
printf("Hello World");
or a HP49?
printf("Hello World");
Sure, some things are different (such as hardware specific to each model). The underlying language can remain constant.
>Modern calculators are just PDAs anyway, with less RAM and a different UI."
That's an opinion, not necessarily a fact
==
The HP49 shares the same CPU as HP's PDAs. Casio AFXs have an '86 CPU that run DOS. The Casio Classpad has a far faster CPU than my first computer. The Saturn is dead, long live the Saturn.
>but I think that giving a Java solution with timings acquired on a Pentium IV at 3.2 Ghz for a 4line challenge intended for ancient calculators is simply missing the mark by a parsec or so.
Of course it is. But you can write, compile and debug a program on a desktop PC, and use high quality tools to do it. Once you are satisified that it works, it is a matter of minutes to port it to a calculator and run it. It's clearly easier than trying to write and RPN program on a model with limited memory.
Best wishes,
.
▼
Posts: 362
Threads: 30
Joined: Jul 2005
For the newest calculators, I believe the challenge should be that the program should be input as a source on the calculator and compiled with the tools included with the calculator.
I was thinking of doing MC9 in ARM assembly but didn't due to time and most importantly because you can't do it directly on the calculator with the built in tools.
For me, if you can enter the program from the source on the calculator you are OK. Now we just need a calculator with a built in C compiler. (I believe CASIO produced a few)
Arnaud
▼
Posts: 123
Threads: 7
Joined: Jan 1970
I think that is the fairest solution.
.
Posts: 614
Threads: 66
Joined: Jul 2006
Hi Valentin,
Thank you for your detailed reply.
I guess I differentiate between what I consider a calculator and the small pocket computers which use Basic as their primary language. I love using both. The main difference between programming a problem in Basic on the Pocket PC as opposed to programming it on a full size PC is one of keyboard and screen size. Both have similar instruction sets. I guess I'm missing what the challenge is in using Basic to solve the problem  other than the fun of typing it on a small keyboard :)
You state that by using the HP71B, more people could run your solution and that the Basic is easier to understand. I appreciate both arguments. And I can appreciate your time constraints  I also have trouble finding free time to play with my HP's.
But there are several HP41 emulators, a HP42S emulator, and several suimulators  plenty of ways for people to check out a RPN program.
Since I use my HP's on a daily basic, I'm always looking for programs and algorithms to analyze so that I can improve my RPN programming capability. From your Datafile articles, I know how good your RPN programming is and was hoping I could analyse your solutions to the challengers.
"Then submit one yourself, so that everyone can see how it's done."
As I said, I didn't have much luck with solving it. If I had, I would have definetly posted it.
Still working on the current challenge and looking forward to the next one.
Bill
12345
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi again, Bill:
Bill posted:
"The main difference between programming a problem in Basic on the Pocket PC as opposed to programming it on a full size PC is one of keyboard and screen size. Both have similar instruction sets."
I see you've done very little programming in HP71B's BASIC. If that's the case, believe me, your "similar instructions sets" couldn't be farther from the truth. When compared to typical BASICs of its time (say, Microsoft BASIC, IBM's BASICA, or GWBASIC), it's lightyears ahead from them, specially when you take into account the powerful extensions to its already awesome instruction set afforded by such plugsin as the Math ROM, HPIL ROM, etc.
As such, programming most nearly everything in HP71B's BASIC is a unique, enthralling experience, where sheer power and, paradoxically, utter simplicity become so intimately intertwined as to make it all a most rewarding activity. Gone are the struggles to try and fit everything within the constraints of RPN. Gone are the headaches associated with trying to use RPL, where there are simply so many available functions, types, objects, structures, everyone of them with their different parameters, quirks, response to flags, etc, that you simply lose focus.
As you may have seen, most of my challenges, even the ones you find difficult to solve, can be dealt with in 3,4, or 5 lines of HP71B BASIC. Recently, one of my published articles in Datafile showed how to solve a complicated engineeringmath problem (finding all eigenvalues, real or complex, of an arbitrary NxN square matrix) in exactly 5 lines of code.
Just try it in MS BASIC, BASICA, GWBASIC, or even Visual BASIC .NET, for that matter. You'll be amazed at the enormous difficulty of the task, and the number of lines of code it takes.
By the way, this doesn't mean I'll limit my challenges and/or solutions just to the 71B, of course. I'll also publish RPNspecific challenges and will give RPN solutions when time permits.
Best regards from V.
▼
Posts: 74
Threads: 10
Joined: Jan 1970
Quote:
As you may have seen, most of my challenges, even the ones you find difficult to solve, can be dealt with in 3,4, or 5 lines of HP71B BASIC.
Valentin, what I particularly don't like in your solutions is the fact that you tend to fill the lines with as many instructions as fit. I always try to write code in a way that is not only legible to computers but to me as a human as well.
So 3 to 4 lines will easily become 20 to 30 instructions. Still much less than any keystroke program and still much easier to understand than any RPL program (I gave up on my 48) regardless of formatting.
I love the challenges but I don't have the time to do them all (I posted what I believe could be a working algorithm, at least).
Keep on challenging!
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi again, Bill:
Bill posted:
"I'm always looking for programs and algorithms to analyze so that I can improve my RPN
programming capability. From your Datafile articles, I know how good your RPN programming is and was hoping I could analyse your solutions to the challengers."
Lest you think I post my solutions in 71B's BASIC out of laziness or RPN shyness, here's a direct translation of my original 71B solution to case (1), namely:
100 SUB SR(N,L) @ FOR I=MOD(L,2)+4*(L=5) TO 9 STEP 2+3*(L=5)
110 IF FLAG(I) THEN 130 ELSE M=N+I @ IF MOD(M,L) THEN 130
120 SFLAG I @ IF L<9 THEN CALL SR(10*M,L+1) @ CFLAG I ELSE DISP M*10 @ CFLAG I
130 NEXT I
to genuine, HP42S RPN code:
01*LBL "SR" 24 1 47 RCL 00 70 RCLx IND 03
02 CF 00 25 + 48 2 71 STOP
03 CF 01 26 STO 03 49 MOD 72 GTO 04
04 CF 02 27 X<>Y 50 + 73*LBL 02
05 CF 03 28 STO IND 01 51 STO IND 02 74 10
06 CF 04 29 RCL 00 52*LBL 01 75 RCLx IND 03
07 CF 05 30 5 53 RCL IND 02 76 1
08 CF 06 31 CF 15 54 FS? IND ST X 77 RCL+ 00
09 CF 07 32 X=Y? 55 GTO 03 78 XEQ 00
10 CF 08 33 SF 15 56 IP 79 1
11 CF 09 34 3 57 RCL+ IND 01 80 STO 00
12 0 35 FC? 15 58 STO IND 03 81 3
13 1 36 0 59 RCL 00 82 STO 01
14*LBL 00 37 2 60 MOD 83 STO 02
15 STO 00 38 + 61 X#0? 84 STO 03
16 3 39 1E5 62 GTO 03 85*LBL 04
17 x 40 / 63 RCL IND 02 86 RCL IND 02
18 1 41 0.009 64 SF IND ST X 87 CF IND ST X
19 + 42 + 65 9 88*LBL 03
20 STO 01 43 4 66 RCL 00 89 ISG IND 02
21 1 44 FC? 15 67 X<Y? 90 GTO 01
22 + 45 CLX 68 GTO 02 91 RTN
23 STO 02 46 + 69 10 92 END
To run it, simply set SIZE 31 or greater, and:
XEQ "SR" > 3,816,547,290
you'll get the first (and only) answer in a few seconds. As stated, this program is a direct translation of the original, which is slightly longer (167 bytes vs. 136 bytes for the original), though that's irrelevant as it can easily be optimized to shave off 1020 program steps or more. I refrained from doing it to preserve the parallelism to the original for didactic comparison purposes, and as it runs so fast anyway.
Seeing this RPN code, there are some points I want to make, to further expand what I told you in my answer to your posting of a few days ago:
 The 71B's BASIC code is just four lines, so very compact and extremely easy to grasp at a glance and understand what it is doing and how it does work. On the other hand, the RPN code is much longer, at 92 steps, and only experienced RPN programmers can eventually understand what it is doing, and it probably would take some stepbystep analysis to clarify it all (assuming, of course, that you're *not* aware of the 71B's version, that is !).
 The 71B's BASIC code, being so short and clear, can be easily translated to any other calculator languages, such as RPN (this exact case), RPL, or whatever. Trying to do the same starting from the RPN version is much more troublesome and a lot more work.
 It took me 5 minutes to write the 71B version, including testing and timing it. Copying it for posting was a case of copy & paste and it took just seconds. On the other hand, it took me more than an hour to write, debug, and test the RPN version, even though I was merely translating from the existing BASIC version, and preparing it for posting here meant to painstakingly write down the steps one by one, manually, and doublechecking for accuracy, thus requiring another late night hour.
So I absolutely rest my case: it's a much more efficient use of my limited resources to give my solutions in 71B code and it's much more convenient for the readers, who can then adapt them to their favorite language. Of course, out of sheer human laziness, one would prefer to directly get the solutions in RPN, RPL, or whatever, but be a sport and do some little work yourself, I'm already doing my part, don't you think ?
"Still working on the current challenge and looking forward to the next one."
Thanks for your interest and please do try and post your findings. Remember, it's much easier to come up with some pretty reasonable excuses than to come up with some reasonably pretty solutions (the line's mine). :)
Best regards from V.
Edited: 25 May 2005, 7:50 a.m.
▼
Posts: 275
Threads: 41
Joined: Mar 2010
Just one question, is there enough return level in the HP41 to allow 9 (or 8 ?) deep XEQ 00 ?
BTW here follow an HP86B version of your program (just have to tackle with local variables and recursivity because the HP86 basic does not allow recursivity on user FN). This could be also usefull for Sharp basic ...
list
10 SFLAG "" @ DIM n(9),i(9)
20 t=TIME @ l=1 @ n(l)=1 @ GOSUB 100
30 DISP "fini ";TIME t @ END
100 i=1+l MOD 2+4*(l=5)
110 IF FLAG (i) THEN 160
120 m=n(l)+i @ IF m MOD l THEN 160
130 SFLAG i @ IF l=9 THEN DISP m*10 @ GOTO 150
140 i(l)=i @ l=l+1 @ n(l)=m*101 @ GOSUB 100 @ l=l1 @ i=i(l)
150 CFLAG i
160 i=i+2+3*(l=5) @ IF i<= 10 THEN 110
170 RETURN
517748
Olivier
Edited: 25 May 2005, 8:11 a.m.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Olivier:
Olivier posted:
"Just one question, is there enough return level in the HP41 to allow 9 (or 8 ?) deep XEQ 00 ?"
No. Were it not for that fact, my RPN version would work unchanged on the HP41C, except for the fact that all RCL arithmetic would have to be 'expanded', i.e.: instead of RCLx IND 03 you would have RCL IND 03, *.
The HP15C does have RCL arithmetic, but also can't go deep enough and there's the problem of flags 8 and 9 being 'system flags', i.e. controlling special behavior. Anyway, it is entirely possible to overcome these minor difficulties and come up with a 41C or 15C version.
Thanks for your HP86B version, Olivier.
Best regards from V.
▼
Posts: 275
Threads: 41
Joined: Mar 2010
Yes your program need exactly 8 levels and the HP42S got exactly 8 levels too :).
The HP41 only remember 6 levels of subroutine :(
Olivier
Posts: 614
Threads: 66
Joined: Jul 2006
Hi Valentin,
"Lest you think I post my solutions in 71B's BASIC out of laziness or RPN shyness, here's a direct translation of my original 71B solution to case (1), namely:"
With the amount of time you spend posting, replying to posts, creating challenges, articles for Datafile, and I assume you also have a job that requires your time, I would be the last one to accuse you of being lazy.
Thank you for posting the RPN solution. I'll definetly be enterng it and anaylzing and comparing it to the 71B vesion. Just to let you know, I do enter ALL your 71b programs and run them on my 71B.
"The 71B's BASIC code is just four lines, so very compact and extremely easy to grasp at a glance and understand what it is doing and how it does work"
I've never been a fan of "counting" lines of code as being a reference for whether its good code, easy to grasp, etc. Many times fewer lines just means more stuff on a single line  not necessarily easier to understand. The first thing I do with any program is rewrite it out with many lines in a structured format so that I can visually see the "fornext", "Ifthen" statement groups lined up. That's the only way I can visually see the program structure.
"Of course, out of sheer human laziness, one would prefer to directly get the solutions in RPN, RPL, or whatever, but be a sport and do some little work yourself, I'm already doing my part, don't you think ?"
I don't like to think of myself as being lazy, and maybe I don't post all my program results but I think you will find that I do "some work myself" and I have posted some of my results in the past and will be posting more results in the future.
"Remember, it's much easier to come up with some pretty reasonable excuses than to come up with some reasonably pretty solutions "
I totally agree. I don't think you'll ever find any of my solutions "Pretty" <g>.
Bill
12345
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Bill:
Bill posted:
"With the amount of time you spend posting, replying to posts, creating challenges, articles for Datafile, and I assume you also have a job that requires your time [...]"
Yes, I'm working right now in four commercial projects at a time, namely an VB 6 project, an VB.NET project, a Netbeans project and, last but not least, a Struts project. Not to mention I also have a wife and a preteen daughter to attend to, plus I'm finishing three Datafile articles and a couple of private programming projects ... and YetAnotherS&SM Challenge ! :)
"Thank you for posting the RPN solution. I'll definetly be enterng it and anaylzing and comparing it to the 71B vesion."
You're welcome. And as I said, they're identical, it's a straightforward translation. BASIC, even when using recursion, translates fairly easily to RPN and vice versa.
"Just to let you know, I
do enter ALL your 71b programs and run them on my 71B."
May I suggest you enter them in Emu71 instead. They'll run orders of magnitude faster, you'll see all results past and present plus full listings in the screen at the same time, and you can copy & paste my listings instead of keying them in, saving time and laborioustofind errors.
And, by the way, do not miss my very next 71B article in Datafile, due next month. I guarantee it's awesome, and I mean it ! :)
"Many times fewer lines
just means more stuff on a single line  not necessarily easier to understand."
I think I already made it clear why I do include as many statements as possible in a single line: to save precious Datafile's space.
"The first thing I do with any program is rewrite it out with many
lines in a structured format so that I can visually see the "fornext", "Ifthen" statement groups lined up. That's the only way I can visually see
the program structure."
I can visualize most any program, whether 'pretty formatted' or not, specially such small routines. Matter of fact, I do tend to prefer them in a compact way, without having to move the eyes down the page to try and find the matching NEXT, say.
"I don't like to think of myself as being lazy"
No offence meant, bad wording on my part. I wasn't implying you personally, it was a general statement. Also, I forgot to plant a smiley at the end.
"I don't think you'll ever find any of my solutions "Pretty""
Who knows ? I've rather have an allegedly nonpretty solution than none at all. Post them and we'll see ...
Best regards from V.
Edited: 25 May 2005, 11:58 a.m.
Posts: 120
Threads: 9
Joined: Aug 2005
Surely the object of the challenge is to get the solution and using a 'calculator' style solution is a makes it all the more interesting. If the solver wants to use a PC then they are the losers.
▼
Posts: 727
Threads: 43
Joined: Jul 2005
Surely the object of the challenge is to get the solution and using a 'calculator' style solution is a makes it all the more interesting.
Couldn't agree more. I guess I'm in the "HP71 is not a calculator" camp  for me, my gut feeling is that a calculator is a small handheld device, with little memory and speed, and which is programmed using keystroke programming. And programming such devices has a certain charm that BASIC just doesn't have  a bit like using assembly language instead of C, very retro, and maybe just a little masochistic. ;)
No disrespect to BASIClovers, of course! To each their own.
 Thomas
Edited: 24 May 2005, 4:59 a.m.
