btw
! Any suggestions?
btw
.
Example:
?- btw([1,2,3,4,5],---,R). R = [1, ---, 2, 3, 4, 5]. ?-
btw
's second result.
Use btw
to implement that second clause. That clause should look something like this:
btw(..., Sep, ...) :- ..., btw(...,Sep,...), ...Don't worry about having the clause do anything more than producing the second result but be sure to use
btw
in the body! The ellipses above imply three or more goals in the body but
you might find a single goal is all you need.
?- btw([1,2,3,4,5],---,R). R = [1, ---, 2, 3, 4, 5] ; R = [1, 2, ---, 3, 4, 5] ; R = [1, 2, 3, ---, 4, 5] ; R = [1, 2, 3, 4, ---, 5] ; false.
Notice that what I've
underlined in the second result sure looks like what btw
would produce if called on the tail of
[1,2,3,4,5]
, huh?!
You might now find that in addition to producing the second result, your btw
is now complete, or almost so! 🙂
(If not, do a7/turnin
, then mail to 372f22
and be sure to mention that you've read this FAQ.)
repl
works fine except for this case:
?- repl(X,2,L), X=7. X = 7, L = [_2638, _2632].A: That behavior commonly arises when
findall
is used. There are issues with, I believe, quantification that I
don't know how to fix. The bottom line is that I don't know of a way to implement repl
using findall
.
Slides 194-195 show a numlist
implementation. It can be simplified to produce a list of identical values. There's also
an approach that uses allsame
from the slides.
append.pl
predicates get "ERROR: Out of global stack"
, like this:
?- mem(1,[1,2]). true ; ERROR: Out of global stackAny suggestions?
A:
If you're blowing out the stack, try tracing. I see this with a faulty mem
that I've named memv2
:
?- trace, memv2(1,[1,2]). Call: (9) memv2(1, [1, 2]) ? creep Call: (10) lists:append(_678, [1], _682) ? creep Exit: (10) lists:append([], [1], [1]) ? creep Call: (10) lists:append([1], _680, [1, 2]) ? creep Exit: (10) lists:append([1], [2], [1, 2]) ? creep Exit: (9) memv2(1, [1, 2]) ? creep true ; Redo: (10) lists:append(_678, [1], _682) ? creep Exit: (10) lists:append([_664], [1], [_664, 1]) ? creep Call: (10) lists:append([_664, 1], _692, [1, 2]) ? creep Fail: (10) lists:append([_664, 1], _692, [1, 2]) ? creep Redo: (10) lists:append([_664|_666], [1], [_664|_672]) ? creep Exit: (10) lists:append([_664, _676], [1], [_664, _676, 1]) ? creep Call: (10) lists:append([_664, _676, 1], _704, [1, 2]) ? creep Fail: (10) lists:append([_664, _676, 1], _704, [1, 2]) ? creep Redo: (10) lists:append([_664, _676|_678], [1], [_664, _676|_684]) ? creep Exit: (10) lists:append([_664, _676, _688], [1], [_664, _676, _688, 1]) ? creep Call: (10) lists:append([_664, _676, _688, 1], _716, [1, 2]) ? creep Fail: (10) lists:append([_664, _676, _688, 1], _716, [1, 2]) ? creep ...Note that there's a sequence of Fails with longer and longer lists for the first argument of
append
, like this:
... Fail: (10) lists:append([_664, 1], _692, [1, 2]) ? creep ... Fail: (10) lists:append([_664, _676, 1], _704, [1, 2]) ? creep ... Fail: (10) lists:append([_664, _676, _688, 1], _716, [1, 2]) ? creepAs humans we can quickly see that
append([...more than one value..., 1], _728, [1, 2])will NEVER be true but those
append
calls plunge away, trying longer and longer lists that end with 1.
This sort of behavior is often seen when the first of two append
goals generates an unfavorable sequence
of alternatives. This problem can often be fixed by doing the append
s in the opposite order.
p.s.
Remember that you can turn off tracing with ?- nodebug.
None yet!
None yet!