Programming puzzles: processing lists!
|
06-05-2017, 01:48 PM
(This post was last modified: 06-05-2017 01:50 PM by Gilles59.)
Post: #121
|
|||
|
|||
RE: Programming puzzles: processing lists!
#16. GoferList
Code:
|
|||
06-05-2017, 02:54 PM
(This post was last modified: 06-05-2017 03:00 PM by pier4r.)
Post: #122
|
|||
|
|||
RE: Programming puzzles: processing lists!
Added the #31 that I thought I already introduced (instead the #30 is part of it).
I solved it making use of a previous release of the David's library (I could not find an updated version with all the listed commands). From 0 to users it is quick if the product is usable. My (slow but useful) solution to #31 (more info: https://app.assembla.com/spaces/various-...stics101.s ) Code:
Wikis are great, Contribute :) |
|||
06-05-2017, 04:49 PM
Post: #123
|
|||
|
|||
RE: Programming puzzles: processing lists!
(06-05-2017 11:38 AM)pier4r Wrote: One thing I noted on hpcalc.org is that people put there great work (even if still in progress) but with little documentation. You have your list package in some post before and that is great, but you missed the documentation in the package. That is, the user should copy your post to procide a "txt" on the 50g to mention how the commands works because one does not always have a link to your post. I certainly don't mind posting interim versions (with whatever command documentation I have), but there's one wrinkle to be aware of: As I add new commands, my inclination is to reorder the command positions alphabetically (with some strongly-related commands side-by-side instead). This allows commands to be more easily located when the library's soft menu is displayed. It also creates a potential problem: older programs stored on your calculator using that library's commands may now be referencing entirely different entries than those when the program was last saved. If you are keeping your source files on your computer as text, this isn't an issue. You would simply need to transfer the files to the calculator again and save them after the new library is installed. |
|||
06-05-2017, 05:33 PM
Post: #124
|
|||
|
|||
RE: Programming puzzles: processing lists!
(06-05-2017 11:48 AM)Gilles59 Wrote: What about a DOPERM command to handle list permutations. I'll think about that. As I'm sure you're aware, the resources of the calculator imply that any command for permutation/combination iteration is likely to have significant limitations. While your given example is certainly feasible, the iterations increase rather quickly with even minimal increases in the numbers. And even if the computation speed can be minimized, processing large lists tends to create memory and garbage collection issues that also hamper overall use of the system. What is the scope of this type of command that you would find reasonable? @Pier: while we're on this subject, challenge #17 isn't realistic for a 50g, unless I'm totally misunderstanding what you've written. Are you really intending to compute/present all 3628800 permutations? If so, your 50g is somehow very different from mine (and you are far more patient than I am). |
|||
06-05-2017, 06:31 PM
(This post was last modified: 06-05-2017 06:35 PM by pier4r.)
Post: #125
|
|||
|
|||
RE: Programming puzzles: processing lists!
(06-05-2017 04:49 PM)DavidM Wrote: I certainly don't mind posting interim versions (with whatever command documentation I have), but there's one wrinkle to be aware of: Since I always end up copying the last version of my source, I would not mind and when I don't copy new stuff, neither I have the need to change the library. Good tip about the library part though, I would have expected that the "call" would have searched the function based on the name, and the location would have been fixed at every new restart. For the #17, I was thinking about using the SD card but it is also true that I should care about the computing time. In userRPL to generate millions of permutations it would take long time. Maybe in sysRPL not. But remember that the challenges are not only for the 50g, in general those are for whatever calculator, even a fast DM42, prime, ti nspire and so on. I'll see with newRPL now that I'm slowly setting it up. Wikis are great, Contribute :) |
|||
06-05-2017, 08:38 PM
Post: #126
|
|||
|
|||
RE: Programming puzzles: processing lists!
#7 HP50G + GoferList
Code: DUP SIZE 2. / Split -1 SWAP + + |
|||
06-05-2017, 09:00 PM
(This post was last modified: 06-05-2017 09:02 PM by Gilles59.)
Post: #127
|
|||
|
|||
RE: Programming puzzles: processing lists!
#9 HP50G + GoferList
Code: « |
|||
06-05-2017, 09:29 PM
(This post was last modified: 06-24-2017 09:30 PM by Gilles59.)
Post: #128
|
|||
|
|||
RE: Programming puzzles: processing lists!
(06-05-2017 05:33 PM)DavidM Wrote: DOPERM The idea is not, in general, to return a list with all the permutations of the list (this is only possible for small list permutations because of the limited RAM). But see this puzzle, for example : Quote: Code:
This will return the list of all the prime numbers with all the 1 3 5 9 7 digits. |
|||
06-06-2017, 01:44 PM
(This post was last modified: 06-06-2017 01:46 PM by pier4r.)
Post: #129
|
|||
|
|||
RE: Programming puzzles: processing lists!
So I was using the LSHF (list shuffle) command from the library of David.
I was curious how solid it was in shuffling the list, since I do not know the algorithm (any chances to share the idea?). So I created the following program: Code:
Now if I'm not mistaken, the chance of an element to end up in a position should be 1/n . Therefore the chances of an element to end up exactly in the original place, should be \( \left (1 - \frac{1}{n} \right )^{n-1} \cdot \left ( \frac{1}{n} \right ) \) . Since there are 'n' original elements, I can sum this term 'n' times. Then the chances that 2 elements ends up in exactly their original place are \( \left (1 - \frac{1}{n} \right )^{n-2} \cdot \left ( \frac{1}{n} \right )^{2} \) The amount of times this can happen are all the possible combinations of 2 elements, so \( \binom{n}{2} \) If I continue and pack this in a formula, plus I consider the resulting matches between the original list and the shuffled list (so I want the expected value of the number of matches), I have: \( \sum_{i=1}^{n} \left [ i \cdot \binom{n}{i} \cdot \left (1 - \frac{1}{n} \right )^{n-i} \cdot \left ( \frac{1}{n} \right )^{i} \right ] \) Once again, if I am not mistaken, this should average (thanks 50g) to 1 match if n=100 . And my test found out that my expectation through formulas seems to match the expectation through computation. So LSHF seems to work very well. Now I'm interested how it works. David could you explain the procedure behind LSHF ? Side note: it is possible that I made a lot of errors together, and by coincidence I got the same result. Wikis are great, Contribute :) |
|||
06-06-2017, 03:24 PM
Post: #130
|
|||
|
|||
RE: Programming puzzles: processing lists!
(06-06-2017 01:44 PM)pier4r Wrote: I was curious how solid it was in shuffling the list, since I do not know the algorithm (any chances to share the idea?). Certainly. LSHF is essentially a faster/more efficient SysRPL implementation of this routine, which you may recognize from another posting: Code: ShufList Its "randomness" is entirely dependent on the quality of the internal RAND function. Although I didn't realize it at the time I wrote it, apparently this method has a name: Durstenfeld's Version of the Fisher-Yates Shuffle. For what it's worth, this came about because I noticed that the previous routine I used ("RANL" from the 1-Minute Marvels) gave biased results. RANL is a bit smaller, but the results seem questionable to me. I'll leave the analysis up to those more qualified. If you take a quick look at sample results from RANL, though, I think you'll quickly see what I'm referring to. Here's a sample run of 20 iterations of running RANL on a single list containing the integers 1-20 in order: { 1 2 3 4 5 6 14 7 20 8 19 9 18 15 17 10 11 16 12 13 } { 1 2 3 4 5 14 6 7 8 9 19 10 18 11 16 15 20 12 17 13 } { 1 2 3 4 5 6 7 8 9 15 20 14 10 11 19 12 18 13 16 17 } { 1 2 3 4 5 6 16 18 7 20 8 9 10 11 15 19 17 13 12 14 } { 1 2 3 17 4 5 6 7 8 14 9 13 10 11 19 12 16 18 15 20 } { 1 2 3 15 4 5 6 12 20 7 8 9 14 16 10 11 13 17 19 18 } { 1 2 3 4 5 6 7 17 16 15 8 19 18 9 10 11 12 20 13 14 } { 1 2 3 20 4 5 6 7 8 9 10 11 19 12 15 18 13 17 16 14 } { 1 2 3 4 5 6 20 14 7 15 18 16 8 9 19 17 13 10 11 12 } { 1 2 3 4 18 5 6 16 7 8 9 19 20 10 11 14 13 12 17 15 } { 1 2 3 4 5 20 6 7 15 8 17 9 14 10 13 11 18 12 19 16 } { 1 2 3 14 4 19 5 6 7 13 8 9 16 10 15 11 20 18 12 17 } { 1 2 3 15 4 5 18 6 7 14 8 9 16 20 10 11 12 17 13 19 } { 1 2 3 15 4 5 6 7 20 8 9 10 12 11 19 18 17 16 13 14 } { 1 2 3 4 5 6 7 8 9 10 18 19 11 20 17 15 16 12 14 13 } { 1 2 16 3 4 5 19 6 15 7 8 9 10 17 14 11 12 18 13 20 } { 1 2 3 16 4 5 6 18 14 7 19 17 8 9 10 11 12 13 20 15 } { 1 2 3 4 5 6 17 18 7 8 15 13 9 10 12 20 14 16 11 19 } { 1 2 3 19 4 15 5 6 7 8 9 10 11 12 13 17 18 16 14 20 } { 1 17 2 3 4 5 6 7 18 8 15 14 9 10 11 12 19 13 16 20 } ...and the same test using the ShufList routine: { 14 10 3 1 12 11 18 19 17 7 13 2 9 4 16 5 20 15 6 8 } { 14 11 8 6 9 1 7 5 19 17 2 13 4 18 3 12 20 10 16 15 } { 3 15 10 6 19 20 11 5 9 16 2 8 4 13 18 17 14 12 7 1 } { 15 8 5 3 1 12 9 2 13 16 11 18 6 14 20 7 19 10 4 17 } { 17 10 5 9 20 11 19 7 18 16 8 6 3 13 2 14 1 12 4 15 } { 13 9 7 11 8 2 16 3 4 20 5 18 14 15 17 6 10 19 12 1 } { 4 17 1 8 16 13 2 11 14 20 19 9 18 10 3 7 6 12 5 15 } { 8 20 2 3 4 16 7 10 17 5 13 14 6 1 18 11 15 9 12 19 } { 2 7 3 8 16 12 17 5 13 1 14 19 10 18 9 15 11 4 6 20 } { 9 3 20 11 5 13 19 2 1 18 7 4 16 8 10 15 6 17 12 14 } { 17 15 6 5 11 3 4 20 16 7 19 13 14 2 8 12 18 10 9 1 } { 18 13 4 20 1 17 5 7 6 15 8 11 10 16 2 9 19 3 14 12 } { 11 4 13 16 6 8 7 12 15 19 2 1 5 18 10 14 9 3 17 20 } { 20 8 3 11 6 18 15 12 4 2 16 9 13 19 1 14 10 17 7 5 } { 6 11 9 12 15 13 4 3 20 2 17 10 19 7 8 14 16 1 18 5 } { 4 10 18 16 20 19 17 3 12 11 7 2 9 15 5 6 8 14 13 1 } { 18 5 11 14 17 15 20 7 19 2 16 3 10 4 1 6 8 9 12 13 } { 18 15 6 10 5 8 4 12 17 13 20 1 3 7 16 9 2 14 11 19 } { 3 6 17 7 10 5 4 19 16 1 13 9 12 18 8 20 11 15 2 14 } { 2 4 14 6 7 1 13 16 3 10 12 19 20 17 5 9 18 8 11 15 } |
|||
06-06-2017, 03:47 PM
(This post was last modified: 06-06-2017 03:47 PM by pier4r.)
Post: #131
|
|||
|
|||
RE: Programming puzzles: processing lists!
Thanks! And the fisher Yates shuffle was already mentioned here: http://www.hpmuseum.org/forum/thread-795...l#pid71847
I did not recognize that in you code (that looks very similar to mine, but I was wondering whether I applied enough shuffles) edit: RANL appears to be quite weak. Wikis are great, Contribute :) |
|||
06-06-2017, 04:36 PM
Post: #132
|
|||
|
|||
RE: Programming puzzles: processing lists!
(06-06-2017 03:47 PM)pier4r Wrote: Thanks! And the fisher Yates shuffle was already mentioned here: http://www.hpmuseum.org/forum/thread-795...l#pid71847 I'm pretty sure that post is where I saw Fisher-Yates referenced the first time. Thanks for pointing it out. Re: RANL, I presume you could achieve better results by calling it repeatedly on a list, but at that point you'd be wasting a lot of time for a few bytes savings. I believe the Fisher-Yates method is sufficient in a single invocation, or should be so long as RAND is adequate. Revisiting this has reminded me that I wanted to test whether I could use the Inside-out method to speed up LSHF by building the shuffled list an element at a time instead of exploding it first. I'm cautiously optimistic about that given the positive results I've seen with some other functions. |
|||
06-07-2017, 08:57 AM
(This post was last modified: 06-07-2017 09:31 PM by pier4r.)
Post: #133
|
|||
|
|||
RE: Programming puzzles: processing lists!
So, surprise surprise.
I wanted to use the David's library to test some properties of the matchmaking procedure of a competitive programming game ( gladiabots ) . Of course my first choice was to do it on 50g, to let the device "suffer" a bit; and because the mathematical library simplifies a lot of operations that on a pc would require specific libraries for programming languages or specific programming languages (scilab, R, and so on). The problem is, summarized: generate a list of 20000 numbers between 1 and 8 (the id of maps in the game). Then pick randomly 1442 of those creating a second list. Then check in this second list how many times the sublist { 1 1 } (or { n n } with n € [ 1, 8 ] ) appears. Note that 5 1 1 1 2 has 2 times the repetition of { 1 1 } . 5 [ 1 1 ] 1 2 and 5 1 [ 1 1 ] 2 . In matchmaking terms it means "how many times, from the perspective of the player, the same map has to be played consecutively (that could be frustrating)". I wanted to compare it with a real sample. I have a sample of 20000 matches and the most active player played 1442 of those 20000. The 50g did the test using the generation of random numbers between 1 and 8 (series of 1442 random numbers, iterated 100 times), I had to wait a bit, but it was possible. The result matched the real sample. The I thought a bit and I proposed to the dev of the game the following. To lower the repetitions of maps and still handling all the maps in a non-predictable pattern (otherwise people may stop playing for a while to avoid maps that they do not like): make a permutation of the maps, consume it, and then make a new permutation, instead of just picking a random map each time that could lead to long repetitions. So I set a program to concatenate random permutations of the same base list ( { 1 2 3 4 5 6 7 8 } ) . To create a final list 20000 long. Then pick 1442 random elements from it (without picking the same position twice) to sort of simulate the activity of a player (not really valid, since a player mostly can play in certain moment of the day), then check how many times the same map appears consecutively as explained above. This is the current code (more info, check assembla) Code:
It is useless to say that after one night it had not finished all the 100 iterations that I wanted (to average the results). So I said to myself. I need something faster with the same rich mathematical (in this case for list operations) environment. I tried the ti nspire, but, as I reported here while Lua is very fast on it, its usage is very clumsly due to the lock down format of the ti nspire files. In short, either one has the ti nspire student software (through which one can create ti basic and lua programs) or one has to create the programs directly on the calculator for the exception of lua, but lua is mostly oriented on graphics. One could export the results from lua to math variables, but then one has to handle those using the calculator itself, without possibility to copy and paste on the Pc. Very, very clumsy. So the ti nspire family for me it is out, I could not believe they made such "closed" system. It is all fine if one has stable final programs to load on the calculator, but for programs that need debug and so, it is absolutely not nice unless one has all the additional TI softwares. (at least this is valid for me when I compared it to the 50g and its workflow) Then there is the newRPL but still I have to find a reliable way to export a program from the simulator. So even that is good for explorations but not big programs that require a lot of debug. Therefore, before checking also HRAST basic (I do not have spare money at the moment), I decided to use the resources available on linux. I thought again about using sqlite, but the random function of sqlite is, well, too verbose to handle to create permutations, so I decided against it. At the end I settled on bash, that is one of the many languages that is not bad to explore (it may be useful afterwards), although quite limited (one has to create its own random function). I wrote the script to run on my little headless server (my preferred choice for little stuff). It has 260 mhz arm processor and 32 mb of ram. Mostly like the prime, but with less optimizations I believe. Well even the bash code, that required a lot of new knowledge (so was good), was super slow. I was actually not expecting bash to take so long to generate the result. So, since the heaviest action was likely the list permutation, I decided to test the two environments. The LSHF of David on my 50g (170 Kb of ram available) Code:
and bash on the 260 mhz arm and 32 mbyte of ram (of which, 6 mbyte free) Code:
100 times shuffling a list of 1000 elements. I hope the two version of the shuffling procedure are very similar (I tried to follow the Fisher-Yate procedure). The results surprised me. I mean with newRPL maybe I would have expected that. Surely with hpgcc, maybe with HRAST BASIC. But userRPL + sysrpl , no, I could not expect that. On the other side, aside that my code in bash could be very slow, I was not expecting such taxing operations for the 260mhz arm device (although in bash there is a lot of array duplication). LSHF testing, shuffling 100 times a list of 1000 elements: 4014 seconds. bash shuffling the same list: 14532 seconds. Woah, really well done David , I could not expect to have such an advantage on the 50g with the original RPL emulation. To do my test I surely need to improve the speed of the bash list shuffle (like generating the result array before hand and then filling it) otherwise, well, it does not work well. edit: My code, mostly within bash, did not help, I was still around 600 seconds for 100 shuffles of a list of 100 elements. Against 83 seconds of LSHF Using a binary, shuf, brought the asus 500 at advantage. 8.8 seconds, but still not as much as I thought. 50g + sysrpl are very impressive. Code:
Wikis are great, Contribute :) |
|||
06-11-2017, 05:51 PM
Post: #134
|
|||
|
|||
RE: Programming puzzles: processing lists!
(06-07-2017 08:57 AM)pier4r Wrote: ...83 seconds of LSHF LSHF should be faster in the attached release. Not as fast as your binary shuf, of course, but on an ARM-based RPL calculator (49g+ or 50g) this version is about twice fast as the previous version in my testing. And that includes the new-and-improved range checking for the RAND seed as well. You'll need to uninstall the previous library before installing this one. There's a handy command for doing that -- it's the last one in the library (so you can simply activate the library menu in the normal way, then go PREV to see it). As a reminder, the command numbers have changed in this version, so be aware that any stored programs using the previous release's commands will now need to be edited appropriately. A text file containing detailed descriptions of each command is included in the zip. Here's a summary of the current commands included: 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 LMRPT - repeats list contents as indicated by count LNDUP - creates a list by repeating an object as indicated by count LREPL - replaces list elements with a substitute object as indicated 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 LSHF - shuffles the contents of a list LSPLT - splits a list as indicated into two sublists LSUM - ΣLIST that also handles lists with 0 or 1 element LSWP - swaps the position of two list elements LXIL - explodes inner sublists into individual elements (non-recursive) LXILR - recursive version of LXIL 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 |
|||
06-11-2017, 07:27 PM
(This post was last modified: 06-11-2017 08:00 PM by pier4r.)
Post: #135
|
|||
|
|||
RE: Programming puzzles: processing lists!
Yay! So this version now is deserving also the gsl or not?
I'll use it ASAP (the best game is to use the 50g +math, why I forgot this for years. The best gaming console that one can get). Edit: installed. I love the "about" thing! How do you get that slick visualization of text? For a flashcard project I would like to show a large string but I do not see (did not try yet) how to activate the scrolling while the program is running. Wikis are great, Contribute :) |
|||
06-11-2017, 09:11 PM
Post: #136
|
|||
|
|||
RE: Programming puzzles: processing lists!
(06-11-2017 07:27 PM)pier4r Wrote: Yay! So this version now is deserving also the gsl or not? Well it's fully functional, and I'm not aware of any issues with any of the commands at this point. But there's still a couple more commands I'm thinking about (DOPERM, DOCOMB), along the lines of what Gilles mentioned earlier. I'd prefer to have the library at the point where the command set is stable before posting to the gsl (or hpcalc.org). (06-11-2017 07:27 PM)pier4r Wrote: I love the "about" thing! How do you get that slick visualization of text? For a flashcard project I would like to show a large string but I do not see (did not try yet) how to activate the scrolling while the program is running. I use a specific SysRPL command (InputLine) to show the About information. It allows lots of customization. I've never tried to do it with UserRPL, but I believe you can do something similar with INPUT. See the description of that command in the AUR. |
|||
06-12-2017, 08:37 AM
(This post was last modified: 06-12-2017 10:05 AM by pier4r.)
Post: #137
|
|||
|
|||
RE: Programming puzzles: processing lists!
So while I'm attacking the #33 I see a similar problem to the #20 (that it is still not solved in RPL, by me at least).
With the #20 I am stuck on debug problems in case of nested iterations on a list, like: Code:
If I try to do this with nested DOSUBS/DOLIST either I am super careful, or debugging it is very taxing. So aside creating my own debug friendly dosubs/dolist (I am not so motivated) what could be workarounds since I need to iterate over a list? Iterating with a FOR index L1 index GET NEXT is super slow for the quick test I made. (maybe in other 50g languages is faster) The library of David gave me an idea (maybe an idea also for him?). Another way to iterate over a list is to rotate the list and get the head. Or consume the list (from the head/tail). Another alternative still is to explode the list before the iteration, and then working on it with stack operations. But that is very messy in stack terms. One has to debug carefully. Therefore I try to ask some more functions for the David Library, of course it is a wish no pressure whatsoever. Having list operations (that I partially coded in userRPL) to iterate over a list in several ways: - L1 listHead: returns on stack 2 the list, without the head, on stack 1 the head of the list { 1 2 3} -> { 2 3 } 1 - L1 listTail: returns on stack 2 the list, without the tail, on stack 1 the tail of the list {1 2 3 } -> {1 2} 3 - L1 <num> listHeadIterate: returns the first <num> elements from the head of the list (in case it repeats making circle of the list), plus the list rotated (so the num+1 element now is in the head). { 1 2 3 4 5 } 2 -> { 3 4 5 1 2 } 1 2 - L1 <num> listTailIterate: returns the first <num> elements from the tail of the list, and then the list rotated { 1 2 3 4 5 } 2 -> { 4 5 1 2 3 } 5 4 - those above could be extended on multiple lists. To partially substitute DOLIST . - other possible functions to iterate over/consume a list (a collection of lists)? (will be interesting to compare those with FOR + get , of course dolist/dosubs will be always faster) I believe if I go through processing challenges using David's library, I'll find a couple more requests for sure. Again, I don't want to make pressure, those are just wishes. (I also believe that through -reasonable- wishes a library can grow very useful) Main source repository changed the url: https://app.assembla.com/spaces/various-...Operations Also #22 Code:
also #33 Code:
Wikis are great, Contribute :) |
|||
06-12-2017, 02:21 PM
(This post was last modified: 06-12-2017 02:21 PM by DavidM.)
Post: #138
|
|||
|
|||
RE: Programming puzzles: processing lists!
(06-12-2017 08:37 AM)pier4r Wrote: So aside creating my own debug friendly dosubs/dolist (I am not so motivated) what could be workarounds since I need to iterate over a list? DOSUBS and DOLIST aren't "debuggable" in the usual manner. The only way I know of to debug this sort of thing is to simply write a test scenario where the stack is pre-loaded with sample contents and then you would put your << ... >> executeable on the stack for evaluation. Tedious, but you can at least step through things to see what happens with one iteration. You could always create a "feeder" app to call that one with several sample inputs. (06-12-2017 08:37 AM)pier4r Wrote: Iterating with a FOR index L1 index GET NEXT is super slow for the quick test I made. (maybe in other 50g languages is faster) ... Another alternative still is to explode the list before the iteration, and then working on it with stack operations. But that is very messy in stack terms. One has to debug carefully. I usually try to avoid GET and PUT operations in any kind of looped operation for that very reason. "Explode-iterate-implode" requires care, but the payoff in performance is good. Most commands in the library I'm working on make use of either that model or a loop of "biting off" one element at a time. (06-12-2017 08:37 AM)pier4r Wrote: - L1 listHead: returns on stack 2 the list, without the head, on stack 1 the head of the list I could put something like this in the library, but it's still fairly easy (and efficient) in UserRPL as well: DUP TAIL SWAP HEAD (06-12-2017 08:37 AM)pier4r Wrote: - L1 listTail: returns on stack 2 the list, without the tail, on stack 1 the tail of the list Similar to the above, but requires a couple of extra REVLISTs. Fortunately, that command is fast (even for large lists): REVLIST DUP TAIL REVLIST SWAP HEAD (06-12-2017 08:37 AM)pier4r Wrote: - L1 <num> listHeadIterate: returns the first <num> elements from the head of the list (in case it repeats making circle of the list), plus the list rotated (so the num+1 element now is in the head). This is similar to a combination of (NEG) LROT with GoferList's Take, though the latter command returns its results in a list. I'm not sure what this would look like with multiple lists; could you provide an example? |
|||
06-12-2017, 04:48 PM
Post: #139
|
|||
|
|||
RE: Programming puzzles: processing lists!
(06-12-2017 02:21 PM)DavidM Wrote: I could put something like this in the library, but it's still fairly easy (and efficient) in UserRPL as well: I have the userRPL (that explodes the list, yours are very compressed in terms of code. Neat) of those commands, I wondered if making a sysRPL version would have been (way) faster. Quote:This is similar to a combination of (NEG) LROT with GoferList's Take, though the latter command returns its results in a list. I'm not sure what this would look like with multiple lists; could you provide an example? Sure, it is all for iterations instead of using DOLIST { 1 2 3 4 5 } { 1 2 3 4 5 } 2 @num list 2 @pick elements from head and rotate lists listHeadIterate output {3 4 5 1 2} {3 4 5 1 2} 1 1 2 2 Wikis are great, Contribute :) |
|||
06-12-2017, 07:24 PM
Post: #140
|
|||
|
|||
RE: Programming puzzles: processing lists!
(06-12-2017 04:48 PM)pier4r Wrote: I have the userRPL (that explodes the list, yours are very compressed in terms of code. Neat) of those commands, I wondered if making a sysRPL version would have been (way) faster. Well in this case barely faster. The UserRPL commands aren't much different from the SysRPL ones in this particular case. But I have no problem adding this, so I went ahead and created a new command "LHDTL" -- here's the detailed description: Code: ______________________________________________________________________________ I don't much like commands that leave varying levels of results, so I chose to return NOVAL for an empty list's first object instead of returning just an empty list. Hopefully that's an acceptable approach. Also, it isn't a stretch to see that "REVLIST LHDTL" will get the last element, and I figured that if you are processing a list from the end you'd probably want to keep it reversed anyway. So I didn't see as much value in adding a separate command to get the last element. (06-12-2017 04:48 PM)pier4r Wrote: Sure, it is all for iterations instead of using DOLIST I've added this to my list of "future considerations". I need to think about this one some more. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)