Threaded Mode | Linear Mode

Thomas Klemm · 07-01-2018, 09:26 PM

(07-01-2018 09:04 PM)Valentin Albillo Wrote: Try that with an RPL program of non-trivial size as I stated.

Remind me on Tuesday, December 21, 2027 if I still understand the UserRPL programs that I've written today in this article.
Of course only if you consider that of "non-trivial size".

Quote:Then why is it so much more fun to write a program using cryptic mnemonics?

I guess that's mostly why I'm hanging around here.

Cheers
Thomas

Valentin Albillo · (This post was last modified: 07-01-2018 09:55 PM by Valentin Albillo.)

(07-01-2018 09:26 PM)Thomas Klemm Wrote:
(07-01-2018 09:04 PM)Valentin Albillo Wrote: Try that with an RPL program of non-trivial size as I stated.

Remind me on Tuesday, December 21, 2027 if I still understand the UserRPL programs that I've written today in this article.
Of course only if you consider that of "non-trivial size".

I don't know if you're a professional programmer. I've been for decades before taking higher responsibilities and even then I did write code whenever I could, so perhaps we do have different criteria on what constitutes "non-trivial size".

For professional projects, many tens of thousands of lines is routine even for medium-sized ones, and even for personal hobbies most of my best projects run into ten thousand lines or twenty. For HP-calc purposes, about 60-100 full 80-char lines is typical for me.

In particular the amount of code in your linked article falls for me in the "trivial size" bin. No offence intended, of course, just saying ...

Regards.
V.
.

Thomas Klemm · 07-01-2018, 10:35 PM

(06-29-2018 11:32 PM)Valentin Albillo Wrote: Even Saturn assembler is much clearer in comparison.

(07-01-2018 09:54 PM)Valentin Albillo Wrote: For HP-calc purposes, about 60-100 full 80-char lines is typical for me.

In particular the amount of code in your linked article falls for me in the "trivial size" bin.

That's great. Thus I assume these 109 lines of SysRPL code to calculate the complex inverse cosine are considered of "trivial size" as well.

I'm mostly interested in the HP-15C assembler code but I'm fine with the HP-71B as well.
Could you provide a similar analysis of this function so we could compare both results?

Many thanks in advance
Thomas

DavidM · 07-01-2018, 10:46 PM

(07-01-2018 08:51 PM)Thomas Klemm Wrote: I'd be interested to know how long it takes on a real HP-28 to verify that 177777773 or 999999999989 are primes.

I don't have a 28 (C or S), but I don't believe the HEAD/TAIL functions exist for those models. At least they don't for the 48sx, so I'd be surprised if they were included on the 28.

So replacing those commands with

HEAD: 1 GET
TAIL: 2 OVER SIZE SUB

...allowed me to at least try your suite on a 48sx. Primality testing for 999999999989 completed in about 75 seconds. The 28 systems would obviously take longer -- someone more familiar with the relative performance of the 28's and 48's could probably give more insight. I know this isn't exactly what you were looking for, but perhaps it will give you some idea of what to expect until someone has the chance to enter the programs on a 28.

Gerson W. Barbosa · (This post was last modified: 07-01-2018 11:14 PM by Gerson W. Barbosa.)

(07-01-2018 10:46 PM)DavidM Wrote:
(07-01-2018 08:51 PM)Thomas Klemm Wrote: I'd be interested to know how long it takes on a real HP-28 to verify that 177777773 or 999999999989 are primes.

I don't have a 28 (C or S), but I don't believe the HEAD/TAIL functions exist for those models. At least they don't for the 48sx, so I'd be surprised if they were included on the 28.

So replacing those commands with

HEAD: 1 GET
TAIL: 2 OVER SIZE SUB

...allowed me to at least try your suite on a 48sx.

1 GET won’t work on the 28S, but 1 DUP SUB will.

The lack of DOERR is also a problem. It’s been suggested to provoke an error, like 0 INV, for instance, but I have yet to figure out where.

PS: I was thinking of a string, but that’s a list, IIRC. So do not take into account what I’ve just said.

Thomas Klemm · 07-01-2018, 11:13 PM

(07-01-2018 10:46 PM)DavidM Wrote: I don't have a 28 (C or S), but I don't believe the HEAD/TAIL functions exist for those models. At least they don't for the 48sx, so I'd be surprised if they were included on the 28.

So replacing those commands with

HEAD: 1 GET
TAIL: 2 OVER SIZE SUB

That should teach me to read the manuals. In this case just using a FOR-loop and use GET might be simpler.

Quote:...allowed me to at least try your suite on a 48sx. Primality testing for 999999999989 completed in about 75 seconds.

Thanks a lot for running the test. I assume that 177777773 takes about the same time.
It's just that the naïve approach would take considerably (~5625 times) longer for 999999999989.

Just for the record: I wrote the program in m48 on the iPhone and the result appears immediately.

Quote:The 28 systems would obviously take longer -- someone more familiar with the relative performance of the 28's and 48's could probably give more insight.

Let me help Gerson with the code for the HP-28.

Quote:I know this isn't exactly what you were looking for, but perhaps it will give you some idea of what to expect until someone has the chance to enter the programs on a 28.

Never mind. Thanks again for your effort.
Thomas

DavidM · 07-01-2018, 11:34 PM

(07-01-2018 11:09 PM)Gerson W. Barbosa Wrote: 1 GET won’t work on the 28S, but 1 DUP SUB will.

That's interesting. The 28C Reference manual included on my museum library thumb drive shows the GET command as being available (and with the expected syntax). Was it removed from or changed somehow for the 28S?

(07-01-2018 11:13 PM)Thomas Klemm Wrote: Thanks a lot for running the test. I assume that 177777773 takes about the same time.

49 seconds on my 48sx.

(07-01-2018 11:13 PM)Thomas Klemm Wrote: Never mind. Thanks again for your effort.
Thomas

You're welcome!

Thomas Klemm · 07-01-2018, 11:39 PM

(07-01-2018 11:09 PM)Gerson W. Barbosa Wrote: The lack of DOERR is also a problem. It’s been suggested to provoke an error, like 0 INV, for instance, but I have yet to figure out where.

COMPOSITE?

Code:

« DUP 1 - → a s d n m

  « a d n POWER

    IF DUP 1 ==

    THEN DROP 0

    ELSE

      IFERR s

        WHILE DUP

        REPEAT

          SWAP

          DUP m ≠ INV

          DROP

          DUP n TIMES

          SWAP 1 -

        END

      THEN SWAP DROP SWAP DROP

      ELSE DROP2 1

      END

    END

  »

»

PRIME?

Code:

« → n 

  « 0 n 1 -

    WHILE DUP 2 MOD NOT

    REPEAT

      SWAP 1 +

      SWAP 2 /

    END → s d

    « { 2 13 23 1662803 }

      IFERR

        WHILE DUP SIZE

        REPEAT

          DUP HEAD s d n COMPOSITE? NOT INV

          DROP

          TAIL

        END

      THEN SWAP DROP

      ELSE DROP 1

      END

    »

  »

»

HTH
Thomas

Gerson W. Barbosa · (This post was last modified: 07-01-2018 11:41 PM by Gerson W. Barbosa.)

(07-01-2018 11:34 PM)DavidM Wrote:
(07-01-2018 11:09 PM)Gerson W. Barbosa Wrote: 1 GET won’t work on the 28S, but 1 DUP SUB will.

That's interesting. The 28C Reference manual included on my museum library thumb drive shows the GET command as being available (and with the expected syntax). Was it removed from or changed somehow for the 28S?

It indeed does work on the HP-28S when the argument is a list. It happens I tested it with a string before realizing your argument was a list. Sorry for the confusion!

Gerson W. Barbosa · 07-02-2018, 12:05 AM

(07-01-2018 11:39 PM)Thomas Klemm Wrote:
(07-01-2018 11:09 PM)Gerson W. Barbosa Wrote: The lack of DOERR is also a problem. It’s been suggested to provoke an error, like 0 INV, for instance, but I have yet to figure out where.

COMPOSITE?

Code:

« DUP 1 - → a s d n m « a d n POWER IF DUP 1 == THEN DROP 0 ELSE IFERR s WHILE DUP REPEAT SWAP DUP m ≠ INV DROP DUP n TIMES SWAP 1 - END THEN SWAP DROP SWAP DROP ELSE DROP2 1 END END » »

PRIME?

Code:

« → n « 0 n 1 - WHILE DUP 2 MOD NOT REPEAT SWAP 1 + SWAP 2 / END → s d « { 2 13 23 1662803 } IFERR WHILE DUP SIZE REPEAT DUP HEAD s d n COMPOSITE? NOT INV DROP TAIL END THEN SWAP DROP ELSE DROP 1 END » » »

HTH
Thomas

Thanks!

177777773: 65 seconds
999999999989: 97.5 seconds

On the HP-28S, HEAD & TAIL replaced with David’s suggestions.

Gerson.

DavidM · 07-02-2018, 12:16 AM

(07-01-2018 11:40 PM)Gerson W. Barbosa Wrote: It indeed does work on the HP-28S when the argument is a list. It happens I tested it with a string before realizing your argument was a list. Sorry for the confusion!

No problem. I probably would have done the same test with a string that you did. Thanks for clarifying!

Thomas Klemm · 07-02-2018, 01:22 AM

(07-02-2018 12:05 AM)Gerson W. Barbosa Wrote: 177777773: 65 seconds
999999999989: 97.5 seconds

Awesome! We might still try to speed that up a bit.

Quote:On the HP-28S, HEAD & TAIL replaced with David’s suggestions.

Would the following using a FOR-loop work?

PRIME?

Code:

« → n 

  « 0 n 1 -

    WHILE DUP 2 MOD NOT

    REPEAT

      SWAP 1 +

      SWAP 2 /

    END → s d

    « { 2 13 23 1662803 }

      IFERR 1 4

        FOR i

          DUP i GET s d n COMPOSITE? NOT INV

          DROP

        NEXT

      THEN SWAP DROP

      ELSE DROP 1

      END

    »

  »

»

PS: Just noticed a problem with the list of witnesses: { 2 13 23 1662803 }
They are marked as composite while they are in reality primes.
Let me sleep on that. Smile

Cheers
Thomas

Gerson W. Barbosa · 07-02-2018, 02:23 AM

(07-02-2018 01:22 AM)Thomas Klemm Wrote: Would the following using a FOR-loop work?

PRIME?

Code:

« → n « 0 n 1 - WHILE DUP 2 MOD NOT REPEAT SWAP 1 + SWAP 2 / END → s d « { 2 13 23 1662803 } IFERR 1 4 FOR i DUP i GET s d n COMPOSITE? NOT INV DROP NEXT THEN SWAP DROP ELSE DROP 1 END » » »

PS: Just noticed a problem with the list of witnesses: { 2 13 23 1662803 }
They are marked as composite while they are in reality primes.
Let me sleep on that.

Yes, exactly the same running times (and the restrictions you have noticed).

Gerson.

pier4r · 07-02-2018, 03:41 PM

(06-30-2018 11:35 PM)Valentin Albillo Wrote: Good for you. Just out of curiosity: what's the result you're eagerly waiting 5-6 days for ? Would you indulge me and describe either the problem or the computation ? Thanks.

Nothing of particular interests (at least for other people). I am simulating the average end score in tournaments based on the Elo's formula. I will make an article once I get enough data. The problem is that it takes time!

It is very similar to this: http://pier4r.wikidot.com/pierworks:arti...formatcomp

Quote:The problem with RePeLent is that it's almost impossible to not write unfathomable "garbage" even if you're trying hard not to be cryptic, and in any case the moment you resort to stack juggling and stack acrobatics for the sake of efficiency you'll immediately plunge head on on cryptography.

Yes this yes. I admire many stackrobatics posted here but until I debug them by hand or on the 50g I cannot really understand what they do. So yes RPL can become a write only language if one doesn't pay care.

Quote:See ? you must picture a worst-case scenario (no named variables, long routines, no comments ...) to try and get "basic" to be "hard to follow" (nope!) while in even the best-case scenario RePeLent is nothing but impossibly hard to follow, to the point of needing to write down the stack after every step to understand what's where. Comparing both languages in this respect is utterly ridiculous.

Hmm I am not sure if I agree here. What I wanted to convey is the following. I am not saying that basic is less readable than RPL. Rather that I consider relatively long code unreadable in whatever language when: it is not explained why the code is in the way it is (so the code misses comments), or the variables are cryptic (1 or 2 letters variables).

Sure, I would repel RPL faster than basic, but ultimately I would avoid both and say "you know what? I write my own routine. I am not sure I can trust this one that is too cryptic for me".

Quote:So you're advocating sacrificing speed for readability, i.e., completely going against what the RPL paradigm posits. Stack juggling is virtually incompatible with "readability".

I advocate that since I realized that "speed" is also developer time and not only execution time. Unless it is a library used plenty of times, eveloper time is the largest part of the whole "solution time". It doesn't matter the language, although some languages are more readable than others until a certain code size.

Yes, RPL (at least the one in the 50g) is not designed for readability. I also believe that it is neither designed for long routines.

Nonetheless I find my approach good enough (until a certain time limit) so I continue to use it. I have 4 50g not for nothing.

Quote:
It's the programming language the one which should be working for me and releasing me of the low-level drudgery, not the other way around.

I agree, but I also see that RPN and RPL had to be squeezed in hw with limits, so they put some burden on the programmer. At least I had this idea until I discovered some years ago that the 71B's basic runs on a saturn chip too. Go figure.

I would have preferred the 71B basic too, with a couple of extension (long variable names & co).

Anyway I have to use the prime more, there a lot of problems disappear. HP PPL is a nice language (with limits, but better than RPL in my opinion).

Valentin Albillo · 07-02-2018, 07:20 PM

.
Hi, Pier:

(07-02-2018 03:41 PM)pier4r Wrote:
(06-30-2018 11:35 PM)Valentin Albillo Wrote: Just out of curiosity: what's the result you're eagerly waiting 5-6 days for ?

I am simulating the average end score in tournaments based on the Elo's formula. I will make an article once I get enough data. The problem is that it takes time!

Ah, I see ... thanks for quenching my curiosity in that regard.

Quote:
Quote:The problem with RePeLent is that it's almost impossible to not write unfathomable "garbage" even if you're trying hard not to be cryptic, and in any case the moment you resort to stack juggling and stack acrobatics for the sake of efficiency you'll immediately plunge head on on cryptography.

Yes this yes. I admire many stackrobatics posted here but until I debug them by hand or on the 50g I cannot really understand what they do. So yes RPL can become a write only language if one doesn't pay care.

Agreed.

Quote:
Quote:See ? you must picture a worst-case scenario (no named variables, long routines, no comments ...) to try and get "basic" to be "hard to follow" (nope!) while in even the best-case scenario RePeLent is nothing but impossibly hard to follow, to the point of needing to write down the stack after every step to understand what's where. Comparing both languages in this respect is utterly ridiculous.

Hmm I am not sure if I agree here. What I wanted to convey is the following. I am not saying that basic is less readable than RPL. Rather that I consider relatively long code unreadable in whatever language when: it is not explained why the code is in the way it is (so the code misses comments), or the variables are cryptic (1 or 2 letters variables).

Semi-agreed. BASIC can almost always be understood and I'm not referring to the algorithm being implemented (which can be difficult) but to the language itself.

Try this: take a BASIC program listing and, without understanding the algorithm or what it does, simply convert the lines to C, C++, C#, Java, Pascal, or whatever. You'll succeed with little trouble as long as you understand both sintaxes, even if you have little or no idea what the original program does or how it does it, you can do the conversion almost automatically, almost in blind fashion.

Now try the same with RPL: take an unfamiliar, non-trivial size RPL program and try to convert it to BASIC, Java, Pascal, C, ... I'll guess that you either won't succeed at all or it will take you an inordinate amount of work and you'll have to resort to actually run or "single-step" the program, review the stack contents all the time, create tons of "stack diagrams", etc, etc.

Quote:Yes, RPL (at least the one in the 50g) is not designed for readability. I also believe that it is neither designed for long routines.

Agreed and agreed.

Quote:
Quote:It's the programming language the one which should be working for me and releasing me of the low-level drudgery, not the other way around.

I agree, but I also see that RPN and RPL had to be squeezed in hw with limits, so they put some burden on the programmer. At least I had this idea until I discovered some years ago that the 71B's basic runs on a saturn chip too. Go figure.

RPN was the most elegant, efficient solution hands down for the times when programmable calculators were price-limited to just a few storage registers (think HP-25) and a few program steps (49, 100, 224, 448). As a programmer, you had to jump through loops as required in order to fit a 4th order Runge-Kutta differential equations solver in a calculator with no subroutines and only 49 program steps while leaving enough steps to program the differential equation itself.

It was also the case (though less so) for the HP-41C and HP42S but shortly after that calculators had more than enough RAM and ROM and CPU speed to implement more sophisticated languages which would take all that drudgery and complicated acrobatics out of the equation and let the programmers concentrate on the real problem at hand to be solved.

HP did that with HP-71B BASIC but a number of factors (price, HP politics, marketing, certain people's agendas ...) completely killed the machine and the approach so there was never a 72B or any other BASIC (or C, or Pascal, or ...) calculators and HP relapsed into aggravated cryptography while SHARP, CASIO, Tandy and many others stole the Programmable Pocket Computer from under HP's feet.

Quote:I would have preferred the 71B basic too, with a couple of extension (long variable names & co).

Agreed. That, removing garbage (CALC mode, etc), compilation and much better hardware would have been a dream machine. Actually, some SHARP PC models almost are.

Quote:Anyway I have to use the prime more, there a lot of problems disappear. HP PPL is a nice language (with limits, but better than RPL in my opinion).

Of course, fully agreed. RPL is a no-contest versus any decent language. Fortunately (and unsurprisingly) only HP supported it (no one else would touch it with a 10-foot pole) but fortunately no more.

As always, thanks for your interesting, thoughtful comments, and best regards.
V.
.

**rprosperi** · 07-02-2018, 11:11 PM

(07-02-2018 07:20 PM)Valentin Albillo Wrote: ... and HP relapsed into aggravated cryptography...

Great phrase Valentin, it's succinct, descriptive and evokes the head-scratching we all have about some decisions in the past.

And though I don't disagree with any of the above comments about the nature of RPL, I still enjoy using it and I find it the best way to simply explore math, lists, memory-diving, etc. interactively (vs. dedicated programs for specific calculations). I've found that if I get curious about something, I likely will build a small RPL program to explore it, while I generally would not on other machines. But, yes, revisiting even my own short programs a few years later proves many of the above criticisms...

pier4r · 07-04-2018, 10:22 AM

(07-02-2018 07:20 PM)Valentin Albillo Wrote: Try this: take a BASIC program listing and, without understanding the algorithm or what it does, simply convert the lines to C, C++, C#, Java, Pascal, or whatever. You'll succeed with little trouble as long as you understand both sintaxes, even if you have little or no idea what the original program does or how it does it, you can do the conversion almost automatically, almost in blind fashion.

Ah understood, so we were looking at different things. I was checking the idea, not the portability. Yes. RPL is not that portable, at least for me.

Said that I continue to use it because, well, I cannot let the 4 50g be idle and I want to use the amazing efforts put in this or that library (admiring the ListExt for example).

Soon I hope to finally start seriously with newRPL instead of doing only micro things with it (the obstable is the win10 system to use).

Valentin Albillo · 07-04-2018, 10:10 PM

,
Hi, Pier:

(07-04-2018 10:22 AM)pier4r Wrote: Ah understood, so we were looking at different things. I was checking the idea, not the portability. Yes. RPL is not that portable, at least for me.

No, we were looking at the same things, it's only that I introduced yet another issue.

Quote:Said that I continue to use it because, well, I cannot let the 4 50g be idle [...]

On the other hand, I own none but if I did it wouldn't be idle either, it would serve 24/7 as either a doorstop or a paperweight ... :-) ... The one and only RPL machine I own is precisely a new-in-box HP28S because I very much like the form factor and the keyboard. Alas, I've never used it and never will.

Quote:[...] and I want to use the amazing efforts put in this or that library.

That's the decades-long problem I've always resented: people will constantly produce this or that library, or this or that utilities ROM, or this or that utilities LEX files and so on and so forth, which are then published and/or made available for free or nearly so, intended to be used in people's own programs and such. So far so good.

Regrettably, most people either don't use them in actual, non-trivial programs or, if they do, they don't make them publicly available so in the end the community rarely gets full-fledged, useful programs but tons upon tons of routines, libraries, utilities, etc., apparently because people love to write libraries and utilities (it's like solving a puzzle or a challenge) but complex, useful programs not so much.

See for example the HP41 series' PPC ROM. Apart from the demonstration examples in its big manual I've very rarely seen "in print" any real application programs calling its functions as part of the program's code, nor have I ever called them from my 41C programs either.

Quote:Soon I hope to finally start seriously with newRPL instead of doing only micro things with it.

Let's hope you succeed. If not, you can always resort to admiring yet another set of libraries or utilities or even create your own in newRPL, will the fun never end ? ... XD

Best regards.
V.
.

ttw · 07-04-2018, 10:52 PM

Complicated problems are not too big a problem. I don't use a computer to program the HP50g (I lost a computer trying to update a Prime so no more connections to computers and no more Primes.) The difficulty is the STRUCTURED PROGRAMMIN (as opposed with structured programming) has some quirks. In general I find that I'm almost always using the default for the work and CASE or IF for exception testing. There is a way out which I did use once. This code segment can be filled in with whatever makes the program work.

J=1 WHILE J REPEAT CASE 1 THEN stuff for initialization whatever 'J' STO END
2 THEN ….stuff whatever 'J' STO END
…
45 THEN stuff 'J' STO END END END

The above is a STRUCTURED PROGRAMMING method of writing code with an arbitrary structure (45 states above); one sets J to zero to exit the region. STRUCTURED PROGRAMMING doesn't help with readability or speed or programming or speed of execution.

I'm polishing a small game (rolling 6 dice several times with complex scoring with 35 or more possibilities depending on previous happenings) on the HP50g. I just noticed I did use the above code in effect. I've got about 40 or so programs (executed from various menus) which return to 2 or 3 distributor-like programs. Instead of IF THEN ELSE structures; one just pushes the button on the menu.

Thomas Klemm · 07-09-2018, 03:24 PM

(07-02-2018 01:22 AM)Thomas Klemm Wrote: We might still try to speed that up a bit.

With the help of Gerald's MMOD program I was able bring it down to:

(07-09-2018 03:12 PM)Thomas Klemm Wrote: Benchmark using HP-48GX
999,999,999,999 → 0 in ~ 8 seconds.
999,999,999,989 → 1 in ~ 31 seconds.
177,777,773 → 1 in ~ 21 seconds.

Cheers
Thomas