List Commands Library for 50g

[DavidM]

(06-29-2017 01:42 AM)John Keith Wrote:  Your example of multiplying, {2} {3} *, works analogously for -, /, and ADD as well.

As they should! I guess that's my point, really. If {2} {3} * works, then why would { {2} {3} } ΠLIST not work? If the function is doing what it is described to do, then the arguments are perfectly valid and the "Bad Argument Type" error makes no sense.

In this (rare ) case, I actually know why it's happening, and it has nothing to do with an intentional error condition being flagged. It's really more an accident that results from calling a user function in a specific way from within another user function, combined with the fact that there isn't a specific branch of "multiply" for handling lists (normally the dispatcher takes care of that). I know why they did it that way, but unfortunately it has the side effect of throwing an error when it wouldn't be expected to by definition.

The whole "+" debacle for lists is a completely different issue. We'll just have to live with that until we can override our firmware with newRPL . If I remember correctly, Claudio identified "+" for lists as something that he intended to work differently with newRPL. I wholeheartedly agree. Was making list catenation like strings really more important than making + like -,*,/? That's hard to believe.

[Gilles59]

Hi,

I have a problem with DOPERM Version 0.9.0d - 2017-06-23

Code:


{ 1 2 3 } 3 «  » DOPERM

returns

[DavidM]

(06-29-2017 07:41 PM)Gilles59 Wrote:  Hi,

I have a problem with DOPERM Version 0.9.0d - 2017-06-23

Very interesting. Never saw anything like that while testing -- not even close. A couple things strike me right off the bat:

- Are you using some kind of stack-replacement/UI-enhancement tool? Or simply an alternate font? Would it be possible to try this again with that turned off to see if makes a difference? I wouldn't think a font change would make a difference, but it's worth trying.
- Could you try a list with three other objects? Some strings would be good... { "A" "B" "C" } should be sufficient. If that works properly, could you try some different numbers other than 1-2-3? (1111 2222 3333 would be an interesting test).

Also, if you don't mind, please execute the following and let me know the results so that I can attempt to duplicate your setup as closely as possible. Please feel free to PM me if you'd rather not post this kind of thing:

Code:

\<<
  VERSION DROP #25EF8h SYSEVAL DROP
  RCLF \->STR "FLAGS" \->TAG
  LANGUAGE\-> \->STR "LANG" \->TAG
  MEM \->STR "MEM" \->TAG
  { 0 1 2 } PVARS \->STR "PVARS" \->TAG
  5 \->LIST \->STR
\>>

It appears that your list is somehow gaining something while things are being processed. Do you know of any reason why exploding your source list would create more than the three values it started with?

[DavidM]

Gilles, one more thing...

If you do the following, what is the string that results?

Code:

{ 1 2 3 }
256 MENU
→H

[Gilles59]

(06-29-2017 11:24 PM)DavidM Wrote:  Gilles, one more thing...

If you do the following, what is the string that results?

Code:

{ 1 2 3 }
256 MENU
→H

Hi David. I try on the emulator not yet my real calc
I get : 47A206B3722C372EC372B2130

PS :I'm in "exact mode"...

PS2 : I tried again and all is OK now :/

[DavidM]

(07-02-2017 04:42 PM)Gilles59 Wrote:  Hi David. I try on the emulator not yet my real calc

Always a good idea when trying new software.

(07-02-2017 04:42 PM)Gilles59 Wrote:  I get : 47A206B3722C372EC372B2130

PS :I'm in "exact mode"...

Thanks! That confirms a common starting point. I've still not been able to replicate this issue, despite trying numerous configuration changes. Did you see my other request? I'd like to be able to replicate your settings as closely as possible.

I probably should have also started with this check:

Code:

HEX
:n:1423 RCL   @ where n is the port number the library is installed in
BYTES

That version of the library should return:

Code:

# A741h
6537

If it doesn't, then the library file that's installed in your emulator is corrupted and should be reinstalled.

If the checksum and byte count listed above match what you're seeing, then I really need to know what else is different about your configuration vs. the different setups I've tried. The results of the small program I posted earlier would be very helpful.

[DavidM]

(07-02-2017 04:42 PM)Gilles59 Wrote:  PS2 : I tried again and all is OK now :/

Just saw this note. Is it possible that you have reinstalled the library since the first time you ran it?

One thing that I have seen in the past is that occasionally the process of downloading/unzipping/transferring/installing binary objects (like libraries) can introduce corruption in a file if one of those steps was processed in a "text" mode instead of binary... it has come up as an issue for me on multiple occasions. Is it possible that something like this may have happened here?

[Gilles59]

(07-02-2017 05:24 PM)DavidM Wrote:  

(07-02-2017 04:42 PM)Gilles59 Wrote:  PS2 : I tried again and all is OK now :/

Just saw this note. Is it possible that you have reinstalled the library since the first time you ran it?

One thing that I have seen in the past is that occasionally the process of downloading/unzipping/transferring/installing binary objects (like libraries) can introduce corruption in a file if one of those steps was processed in a "text" mode instead of binary... it has come up as an issue for me on multiple occasions. Is it possible that something like this may have happened here?

David I think my problem was just a copy/past problem using HPUserEdit... I will install the lib on my real calc

[Gilles59]

An exemple of DOPERM to solve cryptarithms

https://en.wikipedia.org/wiki/Verbal_arithmetic

HE x HE = SHE

Code:


«
 { 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. } 3.
 « 
  { 'S' 'H' 'E'}  STO
  IF '(SQ(10.*H+E)==1E2*S+10.*H+E) AND (S≠0) AND (H≠0)' THEN
   { 'S' 'H' 'E'} DUP «RCL» DOLIST = KILL 
  END
 »
 DOPERM 
»

output : { S=6. H=2. E=5. }

[DavidM]

(07-04-2017 08:41 PM)Gilles59 Wrote:  An exemple of DOPERM to solve cryptarithms
...

That's a very good example of how to make use of DOPERM, Gilles! Unfortunately, it's also a very good example of why I need to go ahead and do something I was already thinking about: creating some kind of mechanism for an early exit feature. It pains me to think that you had to resort to a KILL command. Ouch.

While I am loathe to do anything that will slow down these commands, I think the potential benefit from building in the early exit checks will outweigh the (hopefully) slight delay.

This becomes a bit more complicated because DOPERM, like the PERM command, is actually both a combination and permutation processor. That means that there's two distinctly different "early exit" concepts: one for the current combination being permuted, and the other for the entire process. My plan is to have two local flags available to the user -- ENDPERM and ENDCOMB. Those will only be available while the command is running, and will be initially set to 0/FALSE at the beginning of operation. If the user program changes either of them to 1/TRUE, DOPERM will respond as follows:

ENDPERM TRUE: All processing will stop and the command will exit gracefully, placing the output of processing into a list as usual.

ENDCOMB TRUE: Any further permutations of the current combination will be skipped, and the next combination will be started for permutation processing.

Does this seem like a reasonable approach? I'm open to other suggestions for how to manage this. While it seems like this should be workable, I don't presume that it's the best way to handle it.

All thoughts are welcome!

[pier4r]

I'm really inactive at the moment . Using the 50g daily tour collect data only but no new rpl /user rpl.

I hope to get back at the end of July.

Anyway I follow the discussion and I support the idea of early exist although the 50g command themselves do not have it. (see dolist/subs)

[DavidM]

(07-04-2017 08:41 PM)Gilles59 Wrote:  An exemple of DOPERM to solve cryptarithms

Code:


«
 { 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. } 3.
 « 
  { 'S' 'H' 'E'}  STO
  IF '(SQ(10.*H+E)==1E2*S+10.*H+E) AND (S≠0) AND (H≠0)' THEN
   { 'S' 'H' 'E'} DUP «RCL» DOLIST = 1 'ENDPERM' STO 
  END
 »
 DOPERM 
»

Being able to put all the test conditions into an algebraic is a nice option for readability, but there's a price to pay: it really slows things down. Just as a test, I timed the above program compared to the following equivalent one, which simply uses standard RPL syntax for the checks instead of an algebraic:

Code:

\<<
 { 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. } 3.
 \<<
  { 'S' 'H' 'E'}  STO
  IF

    @ '(SQ(10.*H+E)==1E2*S+10.*H+E) AND (S≠0) AND (H≠0)'

    H 10 * E + SQ
    S 100 * H 10 * + E +
    ==
    S 0 \=/ AND
    H 0 \=/ AND

  THEN
   { 'S' 'H' 'E'} DUP \<<RCL\>> DOLIST = 1 'ENDPERM' STO
  END
 \>>
 DOPERM
\>>

Both had the same results, but notice the timings:

algebraic tests: 241 seconds
RPL tests: 66 seconds

It might not matter much if you simply leave it to run unattended, but I thought it might be worth noting for folks who aren't aware of the difference.

[rprosperi]

(07-05-2017 10:01 PM)DavidM Wrote:  Both had the same results, but notice the timings:

algebraic tests: 241 seconds
RPL tests: 66 seconds

Wow, thanks for sharing these numbers David.

I've always known that defining an algebraic has a performance penalty (the price for the much easier to read 'normal' equation view) but had no idea it was this dramatic. Enlightening!

[DavidM]

(07-05-2017 10:41 PM)rprosperi Wrote:  Wow, thanks for sharing these numbers David.

I've always known that defining an algebraic has a performance penalty (the price for the much easier to read 'normal' equation view) but had no idea it was this dramatic. Enlightening!

As I've been finding lately, anything related to list processing is a good torture test for performance-related issues (speed/GC/memory consumption).

Those occasional one-off algebraics won't amount to much, but put them in a loop and watch out. And a loop of permutations? This is one of those cases where inserting the algebraic as a comment and then following it with the RPL version is probably worth the investment in time.

It might also surprise some folks to know that the RPL version of that code is actually 5 bytes smaller than the algebraic one. The comment and extra line feeds are lost in compilation, of course, but the extra prologue data attached to the algebraic probably makes for the difference.

[DavidM]

It's time for another release...

This one has a few minor changes to existing commands (mostly related to observing system flag 105 to return either exact integers or reals). But most of the energy went into new commands. Several were directly related to suggestions, a couple from trying out Gilles' cryptarithms, and one from my having worked on Joe's recent odd-number challenge. Though not specifically list-related, that last one seemed to fit well with some of the other commands in the library so it made sense to include it.

See the included documentation for usage notes. As always, please don't hesitate to ask questions or to make suggestions/comments about better approaches or -- perish the thought -- bug reports.

Adding support for the early exit capabilities with DOCOMB and DOPERM was a little trickier than I thought, but not because of the reasons you might think. Setting/checking/observing the flag wasn't the problem. The biggest issue was actually having to alter the supplied user program such that any references to the special flags are converted into local variables. It turns out that the calculator's built-in processing of the user-supplied program assumes those references to be for global variables instead of locals since it doesn't see the locals defined in the code. So I have to seek those out and change them prior to executing the command if they are there. And since they can be nested in layers, finding them involves searching for them recursively in the code object. If I don't do that step, the flags will never be changed by the user-supplied program (and new globals will be created) if you attempt to set the flags.

Hopefully the effort (and growing library size) is worth it!

Edit: The attachment has been deleted; see the first post in this thread for the latest version.
_________________________________________
ListExt Release Notes

Version 0.10.0d
2017-07-09

- Added new commands: LPOS, LPOSL, LPROD, RPTCHR, NL→I, LV→I
- DOCOMB and DOPERM final results are now returned in a single list.
- DOCOMB and DOPERM now allow early exits to be performed based on the user program setting a local flag.
- Changed LSUM to return either a real or ZINT 0 for an empty list depending on setting of System Flag 105 (Approximate/Exact Mode).
- LRPCT observes System Flag 105 setting for repeat counts (real/zint)
- LEQ observes System Flag 105 setting for result (real/zint)
- S→NL observes System Flag 105 setting for result (real/zint)
- Changed the description of the SL→S command to correct a typo.

COMMAND SUMMARY

DOCOMB - feeds indicated combinations of a list to a user-supplied program
DOPERM - feeds indicated permutations of a list to a user-supplied program
LCLLT - collates a list of sublists
LCNT - counts objects in a list
LDDUP - removes duplicates from a list
LDST - distributes list items into sublists (reciprocal of LCLLT)
LEQ - checks list items to see if any do not match
LGRP - replaces repeated elements with a single instance
LHDTL - retrieves the first element in a list while leaving the rest on the stack
LMRPT - repeats list contents as indicated by count
LNDUP - creates a list by repeating an object as indicated by count
LPOS - returns a list of all positions of an object in a list
LPOSL - returns a list of all positions of an object in a list or its sublists
LPROD - ΠLIST that also accepts lists with 0 or 1 element
LRCL - recalls objects identified by variables in a list
LREPL - replaces list elements with a substitute object as indicated
LRLL - rolls the list (equivalent to 1 LROT)
LRLLD - "roll down" the list (equivalent to -1 LROT)
LROT - rotates list elements left or right as indicated by count
LRPCT - list with LGRP elements and another list of the count of each element
LSDIV - subdivides a list into <count> sublists
LSEQ - creates a list of <count> integers as a sequence from 1..<count>
LSEQR - creates a list of integers for the range specified
LSHF - shuffles the contents of a list
LSPLT - splits a list as indicated into two sublists
LSUM - ΣLIST that also accepts lists with 0 or 1 element
LSWP - swaps the positions of two list elements
LXIL - explodes inner sublists into individual elements (non-recursive)
LXILR - recursive version of LXIL
RPTCHR - creates a string of repeated characters
S→NL - converts a string to a list of numbers
NL→S - converts a list of numbers to a string
S→SL - converts a string to a list of characters
SL→S - converts a list of characters to a string
NL→I - converts a list of numbers to an integer
LV→I - converts a list of variables to an integer

[pier4r]

Nice! For the exit strategy wouldn't it be easier to fix flags to be used (like flag 60) instead of parsing the user program ?

[DavidM]

(07-10-2017 05:43 AM)pier4r Wrote:  Nice! For the exit strategy wouldn't it be easier to fix flags to be used (like flag 60) instead of parsing the user program ?

Easier? Definitely. But what would be the fun of that? I had ulterior motives in this case, as there are some other potential uses of locals with those commands and I wanted to make sure I could get them to work properly before investigating those possibilities.

A couple of examples:

- Being able to quickly retrieve the "remnant" elements of a combination (those elements not currently selected)
- Being able to read/manipulate the "control object" for the permutation/combination, thus allowing the user program to "jump ahead" during processing in a controlled way

Enhancing what can be done by the user program object is a careful balancing act, though. The overhead involved with figuring out what to do with the control object could very well erase the benefit of having that feature. Everything that happens in that program object is repeated at the innermost loop level, so there's a steep price to pay for any inefficiencies.

[DavidM]

I was intrigued by Gilles' post referencing the "cryptarithms". Although I've seen them before, I hadn't really spent any time pondering them or their cousins (it seems to me that would include things like the Vietnamese Snake Puzzle and Sudoku). Playing around with a couple of them inspired the creation of a couple of new commands in the library, though.

Following the Wiki link to some examples at the cut-the-knot website showed an example that I couldn't pass up trying, mostly because it seemed directed squarely at me regarding my strange affection for these machines:

Code:

  L O T S
  S O L D
      T O
+   O L D
---------
F O O L S

I quickly saw that a common need for this type of problem was having an ability to translate groups of variables into integers. It seemed like such a feature would also benefit other types of problems as well, and thus the commands NL→I and LV→I were born. Setting up a test for the above "word addition" then becomes:

Code:

  { L O T S }    LV→I
  { S O L D }    LV→I
      { T O }    LV→I
    { O L D }    LV→I + + +
{ F O O L S }    LV→I ==

I also recognized that while it's easy to store a list of values into a list of variables:

Code:

{ 1 2 3 } { A B C } STO

There wasn't an apparent counterpart for recalling them (hence Gilles using DOLIST for that purpose). { A B C } RCL would seem fairly intuitive as a construct, but that syntax was already designed to be used in a different way (it specifies a directory path instead of a list of objects). So LRCL was created to streamline that process.

Code:

{ A B C } LRCL => { 1 2 3 }

It also makes short work of creating a list which shows the labeled contents of variables:

Code:

{ A B C } DUP LRCL =

...creates the following list:

Code:

{ A=1 B=2 C=3 }

[Gilles59]

Just one word : " Bravo !"

You create :
NL→I - converts a list of numbers to an integer

Why not the reciprocal :
I→NL - converts an integer to a list of digits (ex : 1230 -> { 1 2 3 0} )

The Joe Horn challenge (All odd digits), could be solve in a very 'natural' way like this ( "All" is a GoferList command) :

Code:

I→NL << 2 MOD >> All

[DavidM]

(07-10-2017 09:30 PM)Gilles59 Wrote:  Just one word : " Bravo !"

Glad you like it.

(07-10-2017 09:30 PM)Gilles59 Wrote:  Why not the reciprocal :
I→NL - converts an integer to a list of digits (ex : 1230 -> { 1 2 3 0} )

The Joe Horn challenge (All odd digits), could be solve in a very 'natural' way like this ( "All" is a GoferList command) :

Code:

I→NL << 2 MOD >> All

I thought about creating a command like that, actually. But I realized that it was already fairly easy to do like this:

Code:

→STR S→NL 48 -

I may still do it, though, just for completeness.

I would probably still use my original submission along with the RPTCHR command for Joe's challenge, though. There's no looping through elements required (other than the inherent looping that the individual instructions do at Saturn speed). "All" is constrained to loop at RPL speed and would almost certainly be much slower. I do like the simplicity of the sequence you're suggesting, though. It makes this one look complex in comparison:

Code:

\<<
  \->STR
  DUP SIZE "1" RPTCHR
  SWAP OVER AND
  ==
\>>