Post Reply 
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 :)
Find all posts by this user
Quote this message in a reply
11-03-2017, 11:15 PM
Post: #222
RE: Programming puzzles: processing lists!
(11-03-2017 09:42 PM)pier4r Wrote:  
Code:

\<< 12 N 0.1 * +  \>>
1
2118
1
SEQ

A shorter form of what you've already got above would be:
Code:
'N' DUP
12.1
223.8
0.1
SEQ

That completes in about 7.1s as opposed to your original at 12.4s.
Find all posts by this user
Quote this message in a reply
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:

That completes in about 7.1s as opposed to your original at 12.4s.

Interesting, so assuming that the iteration costs in a similar way, the difference was in the function to execute.

Wikis are great, Contribute :)
Find all posts by this user
Quote this message in a reply
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:
«
   1. 2118. FOR N
      « 12. N .1 * + » EVAL
   NEXT
»

This is the RPL program created by the simplified version:
Code:
«
   12.1 223.8 FOR N
      'N' EVAL
   .1 STEP
»

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:
«
   12.1 223.8 FOR N
      N
   .1 STEP
   2118 \->LIST
»

Execution time: 4.9s

I know you didn't want to use any non-native commands for this, but I can't help myself. Smile This is actually a really good example of a situation where LSEQR comes in handy, and the fact that the step value is 0.1 makes this even easier:
Code:
«
   121. 2238. LSEQR
   10. /
»

Execution time: 4.1s, most of which is spent doing that final division. Building the initial list of integers only takes 0.31s.
Find all posts by this user
Quote this message in a reply
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 :)
Find all posts by this user
Quote this message in a reply
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:


 EXPORT GETLST(LST,GETLST)
 //Solves Puzzle #32. POSN≥0.
 BEGIN
 LOCAL II;

  IF SIZE(GETLST) THEN
   RETURN MAKELIST(LST(GETLST(II)),II,1,SIZE(GETLST));
  END;
  RETURN {};//ASKED TO GET NOTHING
 END;
Update: As typed here, the procedure name and parameter name are the same.
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)
List API V1.1: http://www.hpmuseum.org/forum/thread-9411.html
Visit this user's website Find all posts by this user
Quote this message in a reply
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 .

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.

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.
Find all posts by this user
Quote this message in a reply
11-07-2017, 01:55 PM
Post: #228
RE: Programming puzzles: processing lists!
(11-05-2017 10:04 PM)StephenG1CMZ Wrote:  I have implemented #32 multiple GET on the Prime.

That's a nice set of list functions you've created, Stephen! I don't have a Prime to use them on, but they seem to cover a lot of ground. Nice work!
Find all posts by this user
Quote this message in a reply
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.

That's a nice set of list functions you've created, Stephen! I don't have a Prime to use them on, but they seem to cover a lot of ground. Nice work!

Thanks David.
Version 1 now also implements a solution to puzzle #40 (remove all instances of an item from the list).

Stephen Lewkowicz (G1CMZ)
List API V1.1: http://www.hpmuseum.org/forum/thread-9411.html
Visit this user's website Find all posts by this user
Quote this message in a reply
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".

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.

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 :)
Find all posts by this user
Quote this message in a reply
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)
List API V1.1: http://www.hpmuseum.org/forum/thread-9411.html
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 2 Guest(s)