List Commands Library for 50g

[pier4r]

(08-11-2017 02:15 PM)DavidM Wrote:  One of the amazing things about all of these devices is that, no matter how much I learn about what they can do, there's always more to discover. Even the commands that I think I already understand are sometimes used in novel ways at the hands of the creative people that share their insights here.

yes it happens often to me too, not only with the hp50g.

Quote:I'm not sure what it would be like to actually "master" all the built-in commands of something like the 50g, but if one were to achieve that status, there's plenty of other tools to learn about. Just take a couple of minutes looking through any of the other threads here...

For me master is very simple: I know that it exist so I can check the reference. If I do not know that it exist, is way harder to check.

And yes I am slowly reading all the threads of the general forum (ignoring all the archives of the old forum, damn me), there are plenty of nice discussions. The point is, if I do not get experience hands on, it is difficult to remember what I read after a while.

[BruceH]

Some thoughts / suggestions...

1. Is there any special reason why LRLL is not called LROLL? The latter would seem to be more memorable.
2. Allow LSPLT to take a negative value and return an empty list plus the full list.
   (Reminds me of BASIC programming where some implementations allowed negative values for LEFT$ and others didn't.)
3. Introduce an RSPLT.
   (I know it's trivial but getting rid of code in a program that is doing trivial stuff means that the remaining code doing the actual work is clearer.)
4. Change their names to LSPLIT & RSPLIT ;-)
5. LPICK command:
   
   Code:
   

   { "50" "G" "HP" }
{ 3 1 2 }
LPICK
   giving
   
   Code:
   

   { "HP" "50" "G" }
6. A new 'sort by reference' command (LSORT) command:
   
   Code:
   

   { "longest" "longer" "long" }
{ 7 6 4 }
LSORT
   gives
   
   Code:
   

    { "long" "longer" "longest" }
   and perhaps suffix with up/down arrows for ascending / descending.
   

[DavidM]

(08-13-2017 01:38 PM)BruceH Wrote:  Some thoughts / suggestions...

Is there any special reason why LRLL is not called LROLL? The latter would seem to be more memorable.

The only reason was my trying to keep the command names as short as possible. But given that I had the same issue just this morning when playing around with some code, I tend to agree with you that LROLL and LROLLD would be better.

(08-13-2017 01:38 PM)BruceH Wrote:  Allow LSPLT to take a negative value and return an empty list plus the full list.

This would actually make it more consistent with the opposite condition (an argument greater than the list length). So, again, I tend to agree with you.

(08-13-2017 01:38 PM)BruceH Wrote:  Introduce an RSPLT.
(I know it's trivial but getting rid of code in a program that is doing trivial stuff means that the remaining code doing the actual work is clearer.)

Sorry to be dense, but what would RSPLT do? Remove? The "L" in most of the commands is an abbreviation for "List". What does the "R" designate?

(08-13-2017 01:38 PM)BruceH Wrote:  Change their names to LSPLIT & RSPLIT ;-)

Probably makes sense.

(08-13-2017 01:38 PM)BruceH Wrote:  LPICK command...

Nice one. Shouldn't be too difficult... just need to watch for invalid/out-of-bounds conditions. How should negative/0 values be handled? Should identifiers in the selection list be RCL'd?

(08-13-2017 01:38 PM)BruceH Wrote:  A new 'sort by reference' command (LSORT) command:

Code:

{ "longest" "longer" "long" }
{ 7 6 4 }
LSORT

gives

Code:

 { "long" "longer" "longest" }

and perhaps suffix with up/down arrows for ascending / descending.

I've thought about doing something like this for a while, actually. Playing around with a quicksort routine gave me a new appreciation for the internal SORT command, which is quite fast despite the fact that it still has to execute the equivalent of a UserRPL comparison operator for each tested pair. I'm not sure which method the internal SORT command uses, but it appears to be very efficient.

There's actually a couple of things I'd like to spend more time on before attempting something like this, though. Perhaps this could be added in some future 1.1 version.

To all: Bruce has some good ideas here. I'd be especially interested in hearing from others about the commands being renamed; would the (slightly) longer forms present any issues? Are there other commands that would be easier to use with a modified name? Now is the best time to nail this down.

[John Keith]

There is already a command called LSORT so a different name may be appropriate. If your goal is to sort a list by criteria other than numerical or alphabetical order, the GoferLists command Sort does this but it is very slow.

John

[John Keith]

(08-13-2017 02:36 PM)DavidM Wrote:  I'd be especially interested in hearing from others about the commands being renamed; would the (slightly) longer forms present any issues? Are there other commands that would be easier to use with a modified name? Now is the best time to nail this down.

I concur with Bruce that the longer names are more readable. An important consideration is how they appear in abbreviated form in the menus, i. e. that the first five letters are understandable. In that vein I would suggest that LDST be renamed to LDIST which seems much clearer to me.

The only other name that comes to mind is LPOS. I would prefer the name MPOS (as in Multiple POS) because it seems more descriptive of the difference between POS and LPOS. Another (self-interested) reason for the name MPOS is that I would really like to have that command work for strings as well as lists.

I do have one other suggestion which is not name related but I will include it here anyway. I believe that the stack order for RPTCHR should be reversed because having the object on level 2 and the number of objects on level 1 seems more consistent with other RPL commands such as \->LIST or NDUPN.

John

[Werner]

(08-13-2017 02:36 PM)DavidM Wrote:  

(08-13-2017 01:38 PM)BruceH Wrote:  A new 'sort by reference' command (LSORT) command:

Code:

{ "longest" "longer" "long" }
{ 7 6 4 }
LSORT

gives

Code:

 { "long" "longer" "longest" }

and perhaps suffix with up/down arrows for ascending / descending.

I've thought about doing something like this for a while, actually. Playing around with a quicksort routine gave me a new appreciation for the internal SORT command, which is quite fast despite the fact that it still has to execute the equivalent of a UserRPL comparison operator for each tested pair. I'm not sure which method the internal SORT command uses, but it appears to be very efficient.

The RPL SORT routine uses binary insertion. Since insertion in this case is a stack roll, and that has been implemented very efficiently in machine language, you're going to have a hard time beating it using SysRPL only.
It (and my LSORT as well) actually covers Bruce's example, but it must be presented differently:

{ {7, "longest"} {6 "longer"} {4 "long"} }
SORT

returns

{ {4 "long"} {6 "longer"} {7, "longest"} }

Cheers, Werner

[DavidM]

(08-13-2017 04:22 PM)Werner Wrote:  The RPL SORT routine uses binary insertion. Since insertion in this case is a stack roll, and that has been implemented very efficiently in machine language, you're going to have a hard time beating it using SysRPL only.
It (and my LSORT as well) actually covers Bruce's example, but it must be presented differently:

{ {7, "longest"} {6 "longer"} {4 "long"} }
SORT

returns

{ {4 "long"} {6 "longer"} {7, "longest"} }

Glad you saw this post, Werner. And also glad that John was already aware of your LSORT routine, which appears to be quite the speed demon. I have no desire to reinvent this wheel. I'm pretty certain that my Saturn code would be larger and slower than what you've already done anyway.

I wasn't aware that SORT (or LSORT) would handle a list of sublists in the way you've pointed out -- that's a nice way to achieve the desired results.

Combining the two lists:

Code:

{ "longest" "longer" "long" }
{ 7 6 4 }

into the needed format is simple enough with:

Code:

DUP SIZE LSDIV SWAP ADD

...which then leaves it to the user to choose which sort they want to use. After sorting, the combined list elements can be easily separated again if needed:

Code:

LCLLT 2 LSDIV LRLL EVAL

[pier4r]

(08-13-2017 04:22 PM)Werner Wrote:  It (and my LSORT as well) actually covers Bruce's example, but it must be presented differently:

{ {7, "longest"} {6 "longer"} {4 "long"} }
SORT

returns

{ {4 "long"} {6 "longer"} {7, "longest"} }

Cheers, Werner

First thank you (as I thank David and whoever else contributes with open libraries) for your work. I will have to consider it, it may be nifty for some challenges of mine that often requires "recursive sorting" because I have list of lists.

[BruceH]

(08-13-2017 02:36 PM)DavidM Wrote:  Sorry to be dense, but what would RSPLT do? Remove? The "L" in most of the commands is an abbreviation for "List". What does the "R" designate?

Sorry, it is me that is being dense. I had mentally started to read the 'L' in 'LSPLIT' as 'left-split' (since it counts from the left) and so 'RSPLIT' was me thinking of a command for splitting a list but counting from the right. To follow convention it would need to be 'LRSPLIT' or maybe 'LSPLITR'.[1]

Regarding the rest: thanks for being so receptive to my suggestions. I take the point about LSORT already being able to do the 'two list sort' provided they are reformatted using DUP SIZE LSDIV SWAP ADD first, but then there needs to be another 'magic incantation' following the LSORT to strip the number from the sublists to get the desired output. This is exactly my point about trying to remove extraneous code and focusing on the solution. If it helps, I would be more than happy if it were implemented as 'LSORT2' that was simply a wrapper that ran the above commands and then invoked LSORT (although it might need careful testing to avoid issues with sublists in the original list etc).


[1] But that's now starting to sound like a Monty Python sketch.

[BruceH]

(08-13-2017 03:16 PM)John Keith Wrote:  An important consideration is how they appear in abbreviated form in the menus, i. e. that the first five letters are understandable.

Good point. Does anyone know if it is possible for a library to display commands as, for example, 'ROLL' in the menu but enter 'LROLL' when selected?

Since the user would have to navigate through the LIB menu to get there, the menu on display shouldn't be too confusing and it would allow more of the meaningful bit of the name to show.

[DavidM]

Re: LSPLIT<whatever>

"LSPLT" fills up a menu. "LSPLIT" shows as "LSPLI", as would "LSPLITR". So if both of those commands are to be included, you would see LSPLI LSPLI in the menus, but the entire commands would show as normal when keying in a program. Is this a problem? I could see it being a bit confusing for someone who wasn't already familiar with both commands. Then again, I'm not sure how useful any of this is without the documentation anyway. I find myself referring to the documentation more and more now, and I should know the commands better than anyone!

Re: SORT helper

I could see having a specific "wrapper" command that would take two lists (L1 in SL1 and L2 in SL2) and do the following:

- check to make sure both lists have the same element count
- combine them as follows:
- { { L1E1 { L2E1 } } { L1E2 { L2E2 } } ... { L1EN { L2EN } } }
- perform a sort (I can probably check for the existence of Werner's LSORT and use that if present)
- split the lists apart again

I believe forcing them into that structure should protect the objects adequately.

So then the question becomes what to name it. LSORT2 (or LSORT<anything>) would show on the menu as LSORT, which then might be easily confused with a simple sort command. And since a person might easily have 2 lists on the stack anyway, this could be a little riskier than usual -- you might not even realize that you just sorted 2 lists instead of 1 until it's too late. I would probably want to make the two stand out -- call it something like L2SRT (or L2SORT).

Thoughts?

[Joe Horn]

The algorithm used by the 50g's SORT command was mentioned above in this discussion. For what it's worth, here's the listing of SORT from the original HP-48G/GX operating system source code. The code remained the same in the 49G, 49G+, and 50g.

Code:

**miscdoc+*******************************************^******
************************************************************
**
** File:    AUFRList.s Version 1.11, 05/06/93
** Machine: Alcuin
**
************************************************************
**+miscdoc**************************************************

*************************************************************
*************************************************************
* SORT
* 
* Sorts the elements of a list in ascending order.  
* Uses code developed by Joe Horn and released to the public domain.
*
* Input:  {}
*
* Output: {}'
*
*************************************************************
*************************************************************
ASSEMBLE
        CON(1)  (nonALG)+0*(hasHELP)+0*(hasALIAS)+0*(hasPDATA)
RPL
xNAME SORT
:: CK1&Dispatch list dosort
;

NULLNAME dosort
:: :: UseHidden{}:
      :: SWAP NotIDorLAM? ITE FalseFalse TrueTrue 4ROLL
     3NULLLAM{} BIND ( 3: lam? 2: id/lam? 1:n )
     2GETLAM IT {id}>{$} 1GETLAM 
     #1+_ONE_DO (DO)
        1GETLAM ROLL ZERO INDEX@
        BEGIN ?ATTNQUIT
           2DUP SWAP#- #2/ DUP#0<>
        WHILE
           OVERSWAP #-DUP #4+PICK 5PICK 
CODE
    C=PC
sort1    LA(5)    (sort2)-(sort1)
    A=A+C    A
    PC=(A)
ENDCODE
               %1 %= ( will be skipped if args are reals )
           ITE ROTDROPSWAP SWAPDROP
        REPEAT
        ROT2DROP UNROLL
         LOOP 2GETLAM IT {$}>{id} 1GETABND
      ;
      COLA 
   ;
LOCALNAME sort2
   :: CK&DISPATCH1 2REAL 
CODE
    D0=D0+    5    skip %1
    D0=D0+    5    skip %=
        LA(5)    =%>
        PC=(A)        go do %>
ENDCODE
                   2STR STR>STR
                   # 000BB HXS>HXS
                   # 000EE UM>?
                   # 000E1 UM>?
                   # 0001E UM>?
                   # 00066 :: ID>$ SWAP ID>$ SWAP STR>STR ;
                   # 00077 :: ID>$ SWAP ID>$ SWAP STR>STR ;
                   2LIST 
      :: DUPLENCOMP #0=case SETSIZEERR CARCOMP
         SWAP DUPLENCOMP #0=case SETSIZEERR CARCOMP SWAP
         COLA
CODE
    C=PC
sort3    LA(5)    (sort2)-(sort3)
    A=A+C    A
    PC=(A)
ENDCODE
      ;
   ; 
;

[John Keith]

(08-13-2017 11:06 PM)DavidM Wrote:  Re: LSPLIT<whatever>

"LSPLT" fills up a menu. "LSPLIT" shows as "LSPLI", as would "LSPLITR". So if both of those commands are to be included, you would see LSPLI LSPLI in the menus, but the entire commands would show as normal when keying in a program. Is this a problem? I could see it being a bit confusing for someone who wasn't already familiar with both commands.

...

So then the question becomes what to name it. LSORT2 (or LSORT<anything>) would show on the menu as LSORT, which then might be easily confused with a simple sort command. And since a person might easily have 2 lists on the stack anyway, this could be a little riskier than usual -- you might not even realize that you just sorted 2 lists instead of 1 until it's too late. I would probably want to make the two stand out -- call it something like L2SRT (or L2SORT).

Thoughts?

I would consider two different commands that appear the same in menus to be unacceptable. I have seen other user libraries that have that issue and it is confusing and annoying. I would prefer abbreviations that are a bit less readable to ones that are easily confused.

John

[Luigi Vampa]

(08-14-2017 01:51 PM)John Keith Wrote:  [...] I would prefer abbreviations that are a bit less readable to ones that are easily confused.

1 +

[pier4r]

http://www.hpmuseum.org/forum/thread-687...l#pid61406

The original statement of the problem serms lost but it would be interesting to see how shorter the code could be with the list commands of David and goferlist combined.

Is the original statement something like "given a string , find the largest distance between two equal chars in terms of position"?

[DavidM]

(08-21-2017 12:26 PM)pier4r Wrote:  Is the original statement something like "given a string , find the largest distance between two equal chars in terms of position"?

Unfortunately I didn't save Gene's original PDF of the contest description, but after looking at the various entries, I think you've got it.

[pier4r]

Maybe is due to the headache, but I cannot remember any built in command to remove an item from a list (and make the list shorter) nor a list of items from a list.

Like

{ A B C D} 2 DEL -> {A C D}

or
{ A B C D E F} { 2 5 } DEL -> {A C D F}

or also by match

{ A B C D E } { B D} MatchDEL -> { A C E }

Am I missing those or they do not exists?

If those are missing, would them be meaningful enough to add them to the library?

[DavidM]

(08-22-2017 06:36 PM)pier4r Wrote:  Maybe is due to the headache, but I cannot remember any built in command to remove an item from a list (and make the list shorter) nor a list of items from a list.

Like

{ A B C D} 2 DEL -> {A C D}

or
{ A B C D E F} { 2 5 } DEL -> {A C D F}

or also by match

{ A B C D E } { B D} MatchDEL -> { A C E }

Am I missing those or they do not exists?

If those are missing, would them be meaningful enough to add them to the library?

The closest to any of those that I'm aware of is GoferList's "Delete" command, which will delete the first instance of an object from a list. There aren't any commands in the ListExt library that perform the actions you've described above.

[John Keith]

The fastest program that I know for the first example is REL (Remove ELement) from One-Minute Marvels:

Code:

\<< SWAP OBJ\-> 2. + DUP ROLL OVER SWAP - ROLL DROP 3. - \->LIST \>>

To delete multiple objects you can convert the list to a string and use SREPL but that method can be slow for large lists due to the time required for OBJ\-> to convert the modified string back into a list.

John

[DavidM]

(08-22-2017 11:48 PM)John Keith Wrote:  The fastest program that I know for the first example is REL (Remove ELement) from One-Minute Marvels:

Code:

\<< SWAP OBJ\-> 2. + DUP ROLL OVER SWAP - ROLL DROP 3. - \->LIST \>>

To delete multiple objects you can convert the list to a string and use SREPL but that method can be slow for large lists due to the time required for OBJ\-> to convert the modified string back into a list.

John

So may I assume that you would be in support of specialized commands in the ListExt library to delete multiple instances of indexed elements?

To all, some considerations to ponder...

This would seem like a good candidate for a command with an overloaded argument scenario. The first would be:

2: { list of objects }
1: number (index of element to delete)

A second option:
2: { list of objects }
1: { list of indices to delete }

Other considerations:

What is the appropriate result for the following scenarios?

• Index list is empty
• Index list contains a 0
• Index list contains non-numeric elements
• Index list contains negative/fractional numbers
• Index list contains numbers greater than the number of elements in SL2 list
  

What would be an appropriate name for such a command?

Then there's mostly the same considerations for a command that would remove a list of matching elements (as opposed to indexed).