RPL mini-challenge: Create an anti-Identity Matrix

[John Keith]

(05-15-2018 12:22 PM)DavidM Wrote:  ListExt already has a similar list-focused command (LMRPT). It doesn't need the "group size" argument, as that is inherently defined by the list argument itself.

Example:
{ 1 2 3 } 4 LMRPT => { 1 2 3 1 2 3 1 2 3 1 2 3 }

It also accepts a non-list object as the first argument, and in that case simply acts like NDUPN →LIST:

1 4 LMRPT => { 1 1 1 1 }

LMRPT is a relatively good performer. « 30 1 OVER LMRPT SWAP LMRPT » creates a 900-element list in about 0.08s on a 50g.

NMDUP could be useful as a post in the General Software Library, so I'll put something together for that.

NMDUP is quite fast as well. with 10 items on stack, << 10. 200. NMDUP >> takes about 65 milliseconds.

I would also like to see it in the ListExt library despite its similarity to LMRPT.

John

[Claudio L.]

(05-15-2018 03:31 PM)David Hayden Wrote:  

Code:

DUPDUP 2. \->LIST 1. CON SWAP IDN -

With input 30, it takes 2.47 seconds on a 50g.

A modified version of Claudio's program takes 3.4 seconds:

Code:

IDN DUP 1. CON SWAP -

I like your improvement on my short version. I was doing NEG on the identity matrix, way slower than using SWAP and subtracting, that has to save significant time.

Now I can't fully understand why the code above, being the EXACT same commands except you added 2 ->LIST and replaced one DUP with one DUPDUP, would be 30% faster. Isn't it doing the same thing? Or are CON and IDN much faster when you use size arguments in lists?
I just can't explain it.

[pier4r]

Con and idn are quite fast. Matrix generation is fast. matrix operations are a bit slower. For this I meant that one should make a sort of benchmark of all the common operations to see possible pitfalls.

[John Keith]

(05-15-2018 03:31 PM)David Hayden Wrote:  

Code:

DUPDUP 2. \->LIST 1. CON SWAP IDN -

With input 30, it takes 2.47 seconds on a 50g.

A modified version of Claudio's program takes 3.4 seconds:

Code:

IDN DUP 1. CON SWAP -

Interestingly, in exact mode the second program is slightly faster than the first one (4.12 vs 4.14 seconds). Matrix commands do seem to work in mysterious ways.

[DavidM]

(05-15-2018 06:48 PM)Claudio L. Wrote:  Now I can't fully understand why the code above, being the EXACT same commands except you added 2 ->LIST and replaced one DUP with one DUPDUP, would be 30% faster. Isn't it doing the same thing? Or are CON and IDN much faster when you use size arguments in lists?
I just can't explain it.

Load stack with:
{ 30. 30. }
1.

Then
<< CON >> TEVAL
Time: 0.0306

Load stack with:
30. IDN
1.

Then
<< CON >> TEVAL
Time: 0.9141

That's just one run, but the time difference is already apparent.

IDN with a single integer input was only slightly faster than with an array when I checked (0.0309s vs. 0.0399s).

I could understand the time difference for CON a little better if the matrix argument was type 29, because the internal data structure for that type of matrix doesn't have meta data for the matrix dimensions like a type 3 does. But in the above example, the input matrix is a type 3. So it's still a bit puzzling.

Regardless of the reason, the moral of this story is: always pass a list of dimensions to CON. Adding SIZE to the second version of the program yields a time result similar to David Hayden's:

Code:

IDN DUP SIZE 1. CON SWAP -

Time: 2.3818s (one attempt)

[DavidM]

(05-15-2018 03:58 PM)toml_12953 Wrote:  

(05-15-2018 05:45 AM)Gerald H Wrote:  HP 38G solves the problem economically:

Code:

MAKEMAT(I≠J,Ans,Ans):

The Prime works the same way but its execution time is measured in milliseconds.

I still wonder, though, if there's a way to build the matrix on the Prime that would be faster. I'm assuming that MAKEMAT is similar to LCXM on the 50g, in that it probably builds a matrix of a given size by applying the supplied function to every cell. If that's the case, it would seem likely that a more direct route (similar to the fastest entries shown in this thread for the 50g) would produce faster results than MAKEMAT. Of course that speed difference might not be noticed by a human using the Prime.

[DavidM]

(05-15-2018 04:52 PM)John Keith Wrote:  I would also like to see it in the ListExt library despite its similarity to LMRPT.

I almost had something like NMDUP in a very early version of the library (along with a couple other stack-manipulating functions), but opted not to put them in because they really didn't have anything to do with lists. I suppose I set myself up for this by including the string functions, didn't I?

I'm starting to think ListExt should be renamed KSLib (Kitchen Sink Library).

[pier4r]

SKlib . Swiss knife library.