User talk:Chris Pressey/Pseudocode for a Thue interpreter

But does it not waste memory, by stockpiling all candidates when all but one are gonna be discarded anyway? Also, I think it selects a rule at random (amongst applicable rules), but always keep the leftmost (or whatever "index" matches to) candidate for that rule. --Koen (talk) 01:13, 11 November 2012 (UTC)
 * It's based more or less on how the reference interpreter works. You could just pick a random rule, then a random place where it matches, but then, if the rule didn't match anywhere, you wouldn't know that you were done and you'd have to pick another random rule until there were no more viable rules, which would increase the complexity of the code.  (Not that this is relevant, but: there may also be some repercussions as to the random distribution; finding all possible candidates then selecting one is evenly distributed in some sense, but picking a random rule might not be.)
 * OK, I see what you mean in your second sentence; I think I addressed that in the implementation, but I'll fix the pseudocode. Chris Pressey (talk) 11:37, 12 November 2012 (UTC)
 * Well, Thue specifications really don't say anything about how the nondeterminism should be handled. For instance, if the program state is:

a::=x b::=y ::= baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 * then do you want to have 99% chance of applying rule  and 1% , or do you want 50% of each? And if the program state was :

a::=0 a::=1 a::=2 a::=3 a::=4 a::=5 a::=6 a::=7 a::=8 b::=9 ::= aab
 * then the current version of your pseudocode would give (correct me if I'm wrong) 18/19 chances of replacing an a, and 1/19 chance of replacing the b (because every a is counted as 9 candidates). Two other interpretations could be 9/10 chances of replacing an a (because 9 out of 10 applicable rules would do so), or 2/3 chances or replacing an a (because 2 out of 3 replaçable substring in the text is "a").
 * Oh, and I guess in some cases it could be better not to seek randomness, but to give priority to rules (or candidates) that have used the most recently - that could speed up, for instance, the brainfuck interpreter in Thue I wrote (because if you're in the middle of interpreting the instruction, you don't need to bother with the hundreds of rules that only concern loops). --Koen (talk) 13:26, 12 November 2012 (UTC)
 * Indeed, as I see it, the word "nondeterministic" means exactly that we don't know what order the evaluation proceeds in. A Thue interpreter which always picked the first (leftmost) match of the first matching rule would still be a conforming Thue interpreter.  But a program written in Thue which relied on this ordering would not be a conforming Thue program.  So there is no reason to write a randomly-substituting Thue interpreter except perhaps tradition, and to emphasize that there is no ordering guarantee (which could aid in developing proper Thue programs which do not rely on ordering.)  As to which orderings have desirable or interesting properties (fairness, efficiency, etc.) during evaluation in which circumstances... that's a matter that could bear further study; I'm sure there are lots of possibilities (e.g. most recently used, as you point out, could be more efficient sometimes) but I haven't thought about them much recently. Chris Pressey (talk) 15:35, 12 November 2012 (UTC)