List Commands Library for 50g

[pier4r]

(08-07-2018 01:47 PM)DavidM Wrote:  What's the purpose of the third element in the sublists? Is there a third potential item on each die (something other than a sword or "bam")?

Yes, there are also "diamons" with other dice. I keep everywhere 3 elements as I can have combinations of dice.

Quote:As far as I'm aware, both the internal SORT and Werner's LSORT only look at the first sublist element when sorting a list containing sublists. So the final ordering should be sorted on that first sublist element, but all of the other sublist elements are ignored.

In this particular situation, you could work around that issue by converting the sublists to an integer using NL→I before sorting, then use I→NL to separate them again afterward. The only issue that will come up in that scenario is that you would lose leading 0s, so you'd have to add them back after the I→NL conversion. (hint: left-pad the lists with 0s and use 3 LLAST)

Note that this only works so long as all of the original list's elements are single digits. I→NL always breaks integers into lists of single digits, so this method won't work if any of the original sublist elements are > 9.

Well it is an idea I didn't think about. But yes it could be that the sublist elements gets higher than 9 (say a 4 dice roll with a lot of "swords").
Actually, having the neat I\->NL and NL\->I , one could add math operations between lists (where a list is a list of single digits of a number), at least NL+ (number as list: add), NL-, NL*, NLIDIV (Integer division, let's make things easy at first). Of course then one can include all the possible functions, but having already the four basic integer functions would be golden honey made out of gold. It is a possible side project for listExt users!

Another possible idea is that I make sublists of 4 elements, where the first element represent the value of the remaining 3 elements. In this way SORT and LSORT could help, as they rely on the first element, although the code becomes a bit larger.

I was thinking there was a command that given a list would sort it through a userRPL/sysRPL command specified by the user but I was mistaken, it is not there. My idea was like: inputList sortProgram CSORT (custom sort)

Quote:In the process of experimenting with this, you've shown me that there's a problem with the latest version of LDDUP. It was rewritten to improve efficiency, but the new version appears to fail when the elements being checked are sublists. I've tracked down the cause to the internal SysRPL command EQUALPOSMETA, which I now see treats sublists differently than discrete objects. Essentially, sublists never match with the latest version (and thus aren't culled out), even when they are exactly the same. So that command is broken in the latest release. I'll have to come up with a replacement for EQUALPOSMETA, as it doesn't provide the needed result if the objects being checked are sublists.

I am sorry that you are getting down the rabbit hole of RPL. On the other side it is nice that we are pushing listExt so much! (and entirely by chance!) I like it.

Quote:Regarding the actual modeling you're attempting:

Unless I'm mistaken, your current code only checks the distribution of results for 2 die, so you'd need a third level of nested loops for the third die. Am I understanding your code correctly?

I can think of some other approaches, but they'd probably be a mixed bag with performance. I should have some time later in the week to experiment with this.

here: http://pier4r.wikidot.com/pierworks:arti...nilla-dice

code: https://app.assembla.com/spaces/various-...assiveDark

I started with for loops but I am lazy to adapt the code for each dice arrangement, so I created a recursive function to compute the roll of N dice.
At the moment the code - that may change - is the following.

Code:


gpRecursDiceRoll
  \<<
  
    \->
    @input
    lvDicePos
    
    \<<
      IF
        @if we are at the last dice
        lvDicePos gvNoDice ==
      THEN
        @roll the dice, but before increase the position to roll
        gpIncrDicePos
        
        @now the roll
        gvDiceComposition lvDicePos GET @dice type, we need another extraction
        gvDicePosActual lvDicePos GET @the position to get from the list in L1
        GET @leave the result on the stack
      ELSE
        @the position is smaller.
        @recurse first
        lvDicePos 1 + gpRecursDiceRoll
        
        @then extract the value
        gvDiceComposition lvDicePos GET @dice type, we need another extraction
        gvDicePosActual lvDicePos GET @the position to get from the list in L1
        GET @leave the result on the stack
        
        @and now add with the previous result on the stack
        ADD
      END
    \>>
  \>>

As usual I try first to be effective then to be efficient. I optimize things when I end up waiting too much. So far until 4 dice (1296 combinations, each with at least 4 recursion, so 5184 operations) is ok (it takes like 10 minutes on the real 50g).

I guess the main problem is, beside the processing of the data, how data is represented. If I represent it as sublist of 3 elements then I can use certain operations. If I represent it as vectors, I can use other operationsand so on. And this will help to be faster or slower according to the performance of the operations on certain type of data.

I used list as I know that the amount of available list processing operations is neat and so also development time shrinks. Development time being part of the solution time (running time actually is often a tiny fraction of the solution time).

For example if I use vectors to model the 3 possible results elements (that cannot be summed together), I have all the arithmetic operations but I cannot sort them (to then do LDDUP and LCNT, to get the frequency).
If I use strings, then I have way less available operations. For example when I want to sum the content between two strings keeping their position int the final result.
If I use numbers, then with a lot of sums could be that the original meaning of the digits is lost, and I have to carefully pads zeroes here and there. Besides a number is also more difficult to parse as result and to debug.

Therefore sublist of 3 elements is for me a good choice at the moment.