03-15-2021, 07:54 AM
(This post was last modified: 03-15-2021, 07:54 AM by Eric Piette.)
Hi,
The merging is not done by decision move, I did not say that. They are done by moves computed by the ludemes (by their eval methods) as explained in previous messages.
The term consequence here is right, they come as a sequence, but as a sequence of each move in the list of moves computed by the eval method which is I think you do not get from my explanation.
Not sure what you mean by "poor performance" that's the most performing implementation possible for the consequences, because they are computed only if the legal move is applied, consequently their computation is the fastest in Ludii compare to effect for example (apply ...).
Concerning "... you already complained it is too complicated for you." That's not the file is too complicated, that's just because the file you are sending is not showing only the problem you mention but a bunch of others things with it, so for a person external to the one who write it, that's not possible in a short term to find what you mean and we can not look many hours each file just to find an hypothetical problem. We do our best to help each user, but the user also has to help us to be helped ;)
That one : (and { (<A>) (<B>) (<C>) } (then (<D>)))
And (and { (<A>) (<B>) (<C>) (<D>) } )
Are not equivalent. And differently according to the fact they are in a (then ...) or not.
So if they are not, for the first one you got the legal moves corresponding to A B C, then for each of the legal moves you have the consequence D. And for the second one you have the legal moves corresponding to A B C D
If they are in a (then ....), for the first one, you are computing the legal moves of A B C, then for each of them when applied the computation of D is done, and their moves (according to the moves applied by A B C) will be applied. For the second one, you just apply all the moves of A B C D.
For (and { (<A> (then (<D>))) (<B> (then (<D>))) (<C> (then (<D>))) } )
If you are not in a (then ...), you compute A then D, B then D, C then D as legal moves.
IF you are in a (then ...) you apply the moves of A, then compute D according to A applied on the state to apply it. AND you apply B and compute D according to B applied to the state to apply it, AND finally you apply C then compute D according to C applied to the state and apply it.
For the last question, not 100% sure what you mean, but I guess you mean to use variable like (site) (to) (from) ect....? if that's right, the answer is yes, because they are possible to be used only inside a ludeme, these ones are more considering as iterators rather then variables.
If you are speaking of the variables like (var ....) or (remember ...) ect.... These ones depends if the moves is applied and the moves computed after it. As a general advice, that's better to use them in different states.
Regards,
Eric
The merging is not done by decision move, I did not say that. They are done by moves computed by the ludemes (by their eval methods) as explained in previous messages.
The term consequence here is right, they come as a sequence, but as a sequence of each move in the list of moves computed by the eval method which is I think you do not get from my explanation.
Not sure what you mean by "poor performance" that's the most performing implementation possible for the consequences, because they are computed only if the legal move is applied, consequently their computation is the fastest in Ludii compare to effect for example (apply ...).
Concerning "... you already complained it is too complicated for you." That's not the file is too complicated, that's just because the file you are sending is not showing only the problem you mention but a bunch of others things with it, so for a person external to the one who write it, that's not possible in a short term to find what you mean and we can not look many hours each file just to find an hypothetical problem. We do our best to help each user, but the user also has to help us to be helped ;)
That one : (and { (<A>) (<B>) (<C>) } (then (<D>)))
And (and { (<A>) (<B>) (<C>) (<D>) } )
Are not equivalent. And differently according to the fact they are in a (then ...) or not.
So if they are not, for the first one you got the legal moves corresponding to A B C, then for each of the legal moves you have the consequence D. And for the second one you have the legal moves corresponding to A B C D
If they are in a (then ....), for the first one, you are computing the legal moves of A B C, then for each of them when applied the computation of D is done, and their moves (according to the moves applied by A B C) will be applied. For the second one, you just apply all the moves of A B C D.
For (and { (<A> (then (<D>))) (<B> (then (<D>))) (<C> (then (<D>))) } )
If you are not in a (then ...), you compute A then D, B then D, C then D as legal moves.
IF you are in a (then ...) you apply the moves of A, then compute D according to A applied on the state to apply it. AND you apply B and compute D according to B applied to the state to apply it, AND finally you apply C then compute D according to C applied to the state and apply it.
For the last question, not 100% sure what you mean, but I guess you mean to use variable like (site) (to) (from) ect....? if that's right, the answer is yes, because they are possible to be used only inside a ludeme, these ones are more considering as iterators rather then variables.
If you are speaking of the variables like (var ....) or (remember ...) ect.... These ones depends if the moves is applied and the moves computed after it. As a general advice, that's better to use them in different states.
Regards,
Eric