Programming puzzles: processing lists!
|
11-03-2017, 09:51 PM
Post: #221
|
|||
|
|||
RE: Programming puzzles: processing lists!
(10-31-2017 12:31 PM)DavidM Wrote: ... list 2000 elements 0 or 1 (random) list 1 OVER SWAP MPOS LRMOV : 9.57s on my 50g list \->STR ".1" "" SRPL DROP OBJ\-> : 13.68s seconds on my 50g Not bad in both cases. Wikis are great, Contribute :) |
|||
11-03-2017, 11:15 PM
Post: #222
|
|||
|
|||
RE: Programming puzzles: processing lists! | |||
11-04-2017, 07:56 AM
Post: #223
|
|||
|
|||
RE: Programming puzzles: processing lists!
(11-03-2017 11:15 PM)DavidM Wrote: A shorter form of what you've already got above would be: Interesting, so assuming that the iteration costs in a similar way, the difference was in the function to execute. Wikis are great, Contribute :) |
|||
11-04-2017, 02:35 PM
Post: #224
|
|||
|
|||
RE: Programming puzzles: processing lists!
(11-04-2017 07:56 AM)pier4r Wrote: Interesting, so assuming that the iteration costs in a similar way, the difference was in the function to execute. Definitely. SEQ takes the arguments you give it and constructs a User RPL program out of them. That program is then executed, and anything placed on the stack more recently than the original arguments are imploded into a list. In the case of your original SEQ invocation, this is the program that SEQ creates: Code: « This is the RPL program created by the simplified version: Code: « So you can see there's much less going on in the innermost loop in the second version, which accounts for the difference. The overhead of the FOR loop structure is roughly the same in both cases. This also gives a clue for a somewhat faster version, though there's more to type so I didn't go that direction earlier. Looking at the output of the second version, you can see that there's no need to actually EVAL a single quoted local variable -- it's simpler to place the ID in the inner loop without the quotes. Since we're using constants for all the arguments here, we already know how many elements will be in the final list. That makes it easy to use the following to create the same list result: Code: « Execution time: 4.9s I know you didn't want to use any non-native commands for this, but I can't help myself. ![]() Code: « Execution time: 4.1s, most of which is spent doing that final division. Building the initial list of integers only takes 0.31s. |
|||
11-04-2017, 07:22 PM
(This post was last modified: 11-05-2017 03:17 PM by pier4r.)
Post: #225
|
|||
|
|||
RE: Programming puzzles: processing lists!
Thanks David. I don't mind other commands if they are compact .
Anyway my point was not to create that particular list quicker. Rather if there was something better than SEQ to create a list based on a sequence of numbers. Wikis are great, Contribute :) |
|||
11-05-2017, 10:04 PM
(This post was last modified: 11-10-2017 10:57 PM by StephenG1CMZ.)
Post: #226
|
|||
|
|||
RE: Programming puzzles: processing lists!
I have implemented #32 multiple GET on the Prime.
Code:
I'd suggest they shouldn't be, to minimise the risk of SIZE() measuring the wrong one. (A version with error checking is in my List API: ListGETLIST http://www.hpmuseum.org/forum/thread-9411.html) Stephen Lewkowicz (G1CMZ) |
|||
11-07-2017, 01:45 PM
Post: #227
|
|||
|
|||
RE: Programming puzzles: processing lists!
(11-04-2017 07:22 PM)pier4r Wrote: Thanks David. I don't mind other commands if they are compact . I guess that depends on your definition of "better than SEQ". LSEQ/LSEQR were created for the scenario where you know the start and stop values and the step value is 1 or -1. If that's a good fit, then those commands require fewer arguments (and are 10-30x faster) than SEQ. Even if the step value doesn't match, they may still be useful if the input and output can be easily modified to make it fit (as in your above example). They do require the input to be in the form of integers, though. So if that can't be done easily, they aren't a good fit and wouldn't be appropriate. |
|||
11-07-2017, 01:55 PM
Post: #228
|
|||
|
|||
RE: Programming puzzles: processing lists! | |||
11-09-2017, 11:48 PM
Post: #229
|
|||
|
|||
RE: Programming puzzles: processing lists!
(11-07-2017 01:55 PM)DavidM Wrote:(11-05-2017 10:04 PM)StephenG1CMZ Wrote: I have implemented #32 multiple GET on the Prime. Thanks David. Version 1 now also implements a solution to puzzle #40 (remove all instances of an item from the list). Stephen Lewkowicz (G1CMZ) |
|||
11-10-2017, 07:55 PM
Post: #230
|
|||
|
|||
RE: Programming puzzles: processing lists!
(11-07-2017 01:45 PM)DavidM Wrote: I guess that depends on your definition of "better than SEQ". Thansk for the input, and nice to see that slowly another library is being done. StephenG1CMZ I recommend you to see the library of DavidM to get some more inspiration! Wikis are great, Contribute :) |
|||
11-16-2017, 10:52 PM
(This post was last modified: 11-16-2017 10:53 PM by StephenG1CMZ.)
Post: #231
|
|||
|
|||
RE: Programming puzzles: processing lists!
I have now also implemented a solution to #31 frequencies in my List API for the Prime.
http://www.hpmuseum.org/forum/thread-9411.html Version 1.1. I was surprised to note that implementing the simple solution of first sorting the list, then producing the already-sorted frequencies, seemed quicker than producing the values and frequencies of the unsorted list and then sorting those. Stephen Lewkowicz (G1CMZ) |
|||
12-30-2017, 02:39 PM
Post: #232
|
|||
|
|||
RE: Programming puzzles: processing lists!
Just discovered, thanks to the work of Terje here (I wonder why HP does not release a pdf with the prime help. It would make things way easier, especially for search and bookmarking) that #41 on the prime can be done with the function cumSum.
The more I look into the prime, the more I see a quite extended standard library of commands. Wikis are great, Contribute :) |
|||
12-30-2017, 05:49 PM
(This post was last modified: 12-30-2017 05:55 PM by StephenG1CMZ.)
Post: #233
|
|||
|
|||
RE: Programming puzzles: processing lists!
(12-30-2017 02:39 PM)pier4r Wrote: Just discovered, thanks to the work of Terje here (I wonder why HP does not release a pdf with the prime help. It would make things way easier, especially for search and bookmarking) that #41 on the prime can be done with the function cumSum. One oddity I just noticed was that cumSum({}) returns 0... Many built-ins don't handle empty lists well. But what should the answer be? {} means you can distinguish input {} from input {0} if desired Whereas {0} treats {} as {0}, just like my ListSigmaSum procedure (whereas the builtin SigmaSum fails). I am thinking returning {0} would be better, assuming there is no good reason to return 0. Eddie W Shore has a workaround for some other oddities here: http://www.hpmuseum.org/forum/thread-381...ght=cumSum Stephen Lewkowicz (G1CMZ) |
|||
12-30-2017, 05:58 PM
Post: #234
|
|||
|
|||
RE: Programming puzzles: processing lists!
For a discussion between {} and "error" (same problem in the 50g) I would point to the thread of the library of DavidM, where the question about consistency was discussed.
here: http://www.hpmuseum.org/forum/thread-8555.html Wikis are great, Contribute :) |
|||
02-18-2018, 10:37 AM
Post: #235
|
|||
|
|||
RE: Programming puzzles: processing lists!
added #42 and #42.1
Wikis are great, Contribute :) |
|||
02-20-2018, 11:41 PM
Post: #236
|
|||
|
|||
RE: Programming puzzles: processing lists!
(11-03-2017 09:42 PM)pier4r Wrote: A way that is still feasible to type on the 50g (therefore no help from a qwerty) but it is also quite quick to generate a list equivalent to the following: Just thought I'd return to this one, given the new LASEQ command in ListExt: Code: 12.1 ...yields the result list in about 0.43s on a 50g. It also has about the least amount of required typing you can have for a problem like this, especially if you simply select the command from a menu. |
|||
02-21-2018, 12:18 AM
Post: #237
|
|||
|
|||
RE: Programming puzzles: processing lists!
#39:
Code: \<< #41: Code: \<< |
|||
02-21-2018, 02:09 PM
Post: #238
|
|||
|
|||
RE: Programming puzzles: processing lists!
#41 is easy with GoferLists:
\<< + \>> Scanl1 |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)