Post Reply 
Programming puzzles: processing lists!
04-28-2017, 03:40 PM (This post was last modified: 04-28-2017 04:01 PM by pier4r.)
Post: #56
RE: Programming puzzles: processing lists!
(04-26-2017 01:30 AM)DavidM Wrote:  Here's my attempt at #6:

I have problems with this one (clever function though! I still have to improve a lot to match the ideas). At the end one has \GSLIST that seems not to work when the list to sum is {1. } (I have approximate mode on, and at first I run tests with 10 elements, not 100, to see if I did everything correctly)

Could you confirm?

In the meanwhile I add a 0 to the result list (but it will add to the execution time) because { 1. 0. } works with \GSLIST .


Ok after the fix, your function fails when the entire list is composed by one element (like a 10 element list composed by 10 times 10).

The version I'm using is the following
Code:

    c6DavidM
    \<<
      @ 'src' is the source list
      @ 'tot' is the count of the current list element being checked
      1 \-> src tot
      \<<
        @ the source list has to have all equal numbers grouped together
        src SORT

        2 @ compare two at a time

        @ for each pair of elements:
        \<<
          IF
            @ are these both the same?
            ==
          THEN
            @ the numbers are equal, so increment the total for this number
            1 'tot' STO+
          ELSE
            @ the numbers are different, so leave the current running total for the
            @ result and start a new running total for the next number
            tot
            1 'tot' STO
          END
        \>>
        DOSUBS

        @ add the final total to the result list
        tot +

        @ at this point, we have a list result that shows the counts of
        @ each unique list element encountered

        @ convert the current result list to one that has:
        @ 0's for each pair of counts that matches
        @ 1's for each pair that doesn't match
        \<< \=/ \>> DOSUBS

        @ sum up all the integers in the above result.  If the total isn't 0, then
        @ the list didn't match the stated criteria.
        @\GSLIST "invalid" 'src' IFTE
        
        0 +
          @Pier: adding a 0 to the list because \GSLIST fail with lists of 1 element.
        \GSLIST 0 1 IFTE
          @Pier: normalize the result like my function to compare.
          @ 0 invalid, 1 valid.
      \>>
    \>>

The the input list generator can be found at the link below, it may provide quick debug possibilities.
So now I try to check your second attempt at #3 using the SUB command.

You #3 is very fast!

Recap:

Pier#1: avg: 50 lists of 100 elements 0.15 secs
DavidM#1 avg: 50 lists of 100 elements 1.94 secs
DavidM#2 avg: 50 lists of 100 elements 0.043 secs

Side question. The tester function is the following (the complete code is here)

Code:

    cTesterGeneric
    \<<
      10 @iterations
      10 @listSize
      { } @inputList
      \<< c1vaV1 \>>
       @c1FuncP
      \<< c1DavidM \>>
       @c1FuncDavidM
      \<< c2vaV1 \>>
       @c2FuncP
      \<< c2DavidM \>>
       @c2FuncDavidM
      \<< c3vaV1 \>>
       @c3FuncP
      \<< c3DavidM \>>
       @c3FuncDavidM
      \<< c4vaV1 \>>
       @c4FuncP
      \<< c4DavidM \>>
       @c4FuncDavidM
      \<< c5vaV1 \>>
       @c5FuncP
      \<< c5DavidM \>>
       @c5FuncDavidM
      \<< c6vaV1 \>>
       @c6FuncP
      \<< c6DavidM \>>
       @c6FuncDavidM
      0 @cFuncP
      0 @cFuncDavidM
      { } @timeListP
      { } @timeListDavidM
      { } @posCheckedListP
      { } @posCheckedListDavidM
      0 @listGenFunc
      \<< \<-listSize {3 5} getRandomListFromValues \>>
        @inputListGenC1
      \<< \<-listSize {3 5} getRandomListFromValues \>>
        @inputListGenC2
      \<< \<-listSize -10 10 getRandomList \>>
        @inputListGenC3
      \<< \<-listSize { 0 1 } getRandomListFromValues \>>
        @inputListGenC4
      \<< \<-listSize { 0 1 } getRandomListFromValues \>>
        @inputListGenC5
      \<< \<-listSize c6listGen \>>
        @inputListGenC6
      \->
      iterations
      \<-listSize
      inputList
      c1FuncP
      c1FuncDavidM
      c2FuncP
      c2FuncDavidM
      c3FuncP
      c3FuncDavidM
      c4FuncP
      c4FuncDavidM
      c5FuncP
      c5FuncDavidM
      c6FuncP
      c6FuncDavidM
      cFuncP
      cFuncDavidM
      timeListP
      timeListDavidM
      posCheckedListP
      posCheckedListDavidM
      listGenFunc
      inputListGenC1
      inputListGenC2
      inputListGenC3
      inputListGenC4
      inputListGenC5
      inputListGenC6
      \<<
        inputListGenC6 'listGenFunc' STO
        c6FuncP 'cFuncP' STO
        c6FuncDavidM 'cFuncDavidM' STO
      
        1 iterations
        START
          listGenFunc EVAL 'inputList' STO
          
          inputList cFuncP TEVAL
          @collect the timing
          OBJ\-> DROP
          'timeListP' SWAP STO+
          @ collect the pos checked.
          'posCheckedListP' SWAP STO+
          
          inputList cFuncDavidM TEVAL
          @collect the timing
          OBJ\-> DROP
          'timeListDavidM' SWAP STO+
          @ collect the pos checked.
          'posCheckedListDavidM' SWAP STO+
        NEXT
        
        timeListP
        posCheckedListP
        timeListDavidM
        posCheckedListDavidM
      \>>
    \>>

Now in the input functions, like inputListGenC6, I have to use a compiled variable otherwise the value of "listSize" is not recalled as I think.

For example in \<< \<-listSize c6listGen \>> the behavior when I use a plain "listSize" (instead of the compiled variable) is the following: listSize is saved as 'listSize' in the variable listSizeV of the c6listGen routine. Then in the routine:

\<< n \>> 'n' 1 listSizeV 1 SEQ
works.

While
listSizeV 2 *
returns the algebraic object 'listSize*2'

I thought that variables were properly seen by subprograms in a program, in this case I mean \<< listSize c6listGen \>> should see the value of the variable.
So I thought a compiled variable should not be necessary but so far I don't see a workaround (and I was lucky that so far all the other input functions worked without compiled variables, using only "listSize", that then got changed in compiled variable for challenge 6)

Wikis are great, Contribute :)
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: Programming puzzles: processing lists! - pier4r - 04-28-2017 03:40 PM



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