Pair et de l'Impair listes

Je suis en train de mettre en œuvre un programme Prolog qui va diviser la liste en deux listes. Le premier contiendra les numéros dans la même positions et la seconde le nombre est impair positions.

E. g.: even_odd([1,2,4,7,5],Even,Odd). entraînera Even=[2,7]. et Odd=[1,4,5].

J'ai trouvé plus élégant des solutions que le mien googler le problème, cependant je voudrais savoir où se trouve le problème dans mon code (probablement opérateur abus) parce que je pense vraiment que j'ai une très mauvaise compréhension de Prolog opérateurs (en particulier en arithmétique comparaison). Aussi googler il ne fait qu'empirer les choses, chaque site a une toute autre explication.

Mon code:

even_odd([], [], []).
even_odd([H|T], Even, Odd) :-
    length([H|T], X),
    X mod 2 is 0,
    append(Even1, H, Even),
    even_odd(T, Even1, Odd).
even_odd([H|T], Even, Odd) :-
    length([H|T], X),
    X mod 2 is 1,
    append(Odd1, H, Odd),
    even_odd(T,Even,Odd1).

J'ai essayé de traçage et je sais que le problème réside dans le X mod 2 is 1 ou 0, aucun d'eux n'est jamais vrai. Si j'ai une liste de trois éléments et de la modification des conditions de X is 3 il est tout à fait acceptable, mais la division semble confus, alors, des idées?

InformationsquelleAutor Angelos Chalaris | 2014-01-17

list prolog

3

Arithmétiques opérateur d'évaluation (est)/2 effectue une opération arithmétique sur le droit d'expression, et de l'unifier avec ses de gauche argument, et d'appliquer le test à la mauvaise variable. Devrait être
```
even_odd([H|T],Even,Odd):- 0 is H mod 2,...
```
Sinon, il y a (=:=)/2 qui effectue une opération arithmétique sur les deux côtés. Alors peut être
```
H mod 2 =:= 0
```
En outre, la façon dont vous traitez les listes n'a pas beaucoup de sens. Vous devez mettre la même valeur dans la liste. Puis quelque chose comme
```
even_odd([H|T],[H|Even],Odd):- 0 is H mod 2,...
```
aurait plus de sens.
- POUR veut numéros pair/impair positions, pas avec pair/impair de valeurs.
- oui, merci, j'avais peut-être tache aveugle lors de la lecture de la question
- Eh bien, je sais que ma solution ne fait pas beaucoup de sens après avoir essayé pendant un certain temps, mais le problème c'est principalement pourquoi l'évaluation a échoué. Donc cela répond à ma question pourquoi le chèque était un faux. Il semble fonctionner maintenant! 🙂
InformationsquelleAutor CapelliC
5

Tout CapelliC a la bonne idée sur pourquoi votre code ne fonctionne pas, il a mal compris votre question au sujet de vouloir les paires/impaires positions.

Le problème est, vous êtes le calcul de celles de la fin de la liste, de sorte even_odd([1,2,4,7],Even,Odd). entraînera Even=[1,4]. et Odd=[2,7]. qui n'est pas ce que vous voulez.

Une solution serait d'inverser la liste avant le traitement et à inverser les résultats par la suite, ou de prendre une approche différente.

Ici, nous commençons par l'ajout d'un élément à l'étrange liste, puis en alternance entre l'ajout de au même et à l'étrange liste, jusqu'à ce que nous avons atteint la finale de l'élément.
```
even_odd(List, Even, Odd) :- 
    % First position is odd
    even_odd_odd(List, Even, Odd).

% We handle the odd position, the next is even
even_odd_odd([H|T], Even, [H|Odd]) :- 
    even_odd_even(T, Even, Odd).
even_odd_odd([], [], []).

% We handle the even position; the next is odd
even_odd_even([H|T], [H|Even], Odd) :- 
    even_odd_odd(T, Even, Odd).
even_odd_even([], [], []).
```
- C'est une bonne solution, bien que n'étant pas ce que l'OP demande: j'ai trouvé plus de solutions élégantes que mine de googler le problème, cependant je voudrais savoir où se trouve le problème dans mon code...
- Je suis d'accord, mais il y avait une faille dans leur solution ne pouvait pas être facilement corrigé, sauf par l'ajout de plus kludges comme la réversion avant et après. C'est pourquoi j'ai ajouté cet exemple: il me semble que si ils sont à essayer d'écrire le code de procédure en Prolog. Je pense que c'est d'une importance vitale pour enseigner la bonne façon de penser en Prolog.
- Je viens de penser à un défi intéressant. Faire cela pour un certain nombre de listes, au lieu de deux. Ainsi, par exemple divvy([1,5,4,8,6,4,4,2,0,4], 3, X) ? X = [[1,8,4,4], [5,6,2], [4,4,0]].
- Merci pour l'effort. Bien que mon problème était surtout pourquoi la comparaison a échoué, c'est une bonne solution. Toutefois, j'ai trouvé un plus élégant de toute façon! J'étais juste curieux de savoir pourquoi ma solution ne pouvait pas obtenir passé un certaint point!;)
- Tout à fait +1. Tout ce que peut être exprimée par l'intermédiaire de la correspondance de motif doit être exprimé par filtrage. Le cas des relatives, d'une liste de ses pairs/impairs, les positions peuvent être clairement exprimée par l'intermédiaire de la correspondance de motif, de sorte que cette solution est très souhaitable. Notez que vous pouvez utiliser cette version dans toutes les directions, par exemple: ?- even_odd(List, [a,b,c], [d,e,f])., ce qui n'est pas du tout possible ou conduit à la cessation des problèmes avec moster autres versions et ne fonctionne pas même après avoir appliqué les corrections suggérées.
InformationsquelleAutor SQB
2

Il existe quelques problèmes.

Première est la @CapelliC souligné, c'est que le is/2 prédicat instancie une variable simple sur la gauche avec la valeur d'une expression sur le droit. Le code d'origine est l'expression à gauche et la valeur sur le droit et échoue toujours. Donc ceci:
```
X mod 2 is 1
```
Devrait être changé en:
```
1 is X mod 2
```
Ou, comme @CapelliC dit, X mod 2 =:= 1.

Seconde, votre append tente d'ajouter un seul élément à une liste. append ne fonctionne que sur les listes. Donc:
```
append(Odd1, H, Odd)
```
Devrait être
```
append(Odd1, [H], Odd)
```
Tiers, à l'ordre de append et la récursivité even_odd appel va causer un problème:
```
append(Odd1, [H], Odd),
even_odd(T,Even,Odd1).
```
Odd1 est uninstantiated quand append est appelé, comme c'est Odd. Cela génère un nombre infini de solutions pour la append avant une réponse acceptable peut être lié par le cas de base, résultant en un débordement de pile. La solution simple pour cela est de les échanger:
```
even_odd(T, Even, Odd1),
append(Odd1, [H], Odd).
```
Cela fonctionne maintenant, mais donne des résultats dans l'ordre inverse:
```
| ?- even_odd([1,2,3,4,5,6], E, O).

E = [5,3,1]
O = [6,4,2] ? ;
```
La chose la plus facile à résoudre qui est à ajouter, plutôt que de l'ajouter. Remplacer
```
append(Odd1, [H], Odd)
```
Avec
```
Odd = [H|Odd1]
```
Ou tout simplement l'inclure dans la tête de la clause. Les clauses finales, avec de tous les correctifs, alors ressembler à ceci:
```
even_odd([], [], []).
even_odd([H|T], [H|Even1], Odd) :-
    length([H|T], X),
    0 is X mod 2,
    even_odd(T, Even1, Odd).
    %%Even = [H|Even1].   % equivalent to append([H], Even1, Even)
even_odd([H|T], Even, [H|Odd1]) :-
    length([H|T], X),
    1 is X mod 2,
    even_odd(T, Even, Odd1).
    %%Odd = [H|Odd1].   % equivalent to append([H], Odd1, Odd)
```
Rendement
```
| ?- even_odd([1,2,3,4,5,6], E, O).

E = [1,3,5]
O = [2,4,6] ? ;

no
```
Enfin, il y a un autre problème: la parité sur les listes est déterminée à partir de la fin de la liste, plutôt qu'au début. Cela est dû à la logique de l'aide length sur la liste actuelle fragment comme un moyen de détermination de la parité.

Pour résoudre ce problème, dans la structure du code (encore une fois, la rétrogradation, la solution plus naturelle que @ATS présenté), vous auriez vraiment besoin de compter/index depuis le début. Le regardant avec beaucoup de détails, qui nous amènerait à une solution comme ceci:
```
even_odd(L, Even, Odd) :-
    even_odd(L, 1, Even, Odd).
even_odd([], _, [], []).
even_odd([H|T], C, [H|Even1], Odd) :-
    0 is C mod 2,
    C1 is C + 1,
    even_odd(T, C1, Even1, Odd).
even_odd([H|T], C, Even, [H|Odd1]) :-
    1 is C mod 2,
    C1 is C + 1,
    even_odd(T, C1, Even, Odd1).
```
Qui donne:
```
| ?- even_odd([1,2,3,4,5,6], E, O).

E = [2,4,6]
O = [1,3,5] ? a

no
```
C'est une solution de travail, mais pas du tout optimal car il ne prend pas avantage de la "connaissance" de la position de la liste dans le code (de manière redondante introduit un nombre ou un indice pour savoir où nous en sommes dans la liste).
- Et, comme nous l'avons, nous sommes le calcul de bizarrerie/régularité de la fin de la liste, ce qui peut très bien être le besoin, mais ne sonne pas comme il le serait.
InformationsquelleAutor lurker

Vous devez vous connecter pour publier un commentaire.