Q: FIND-ALL-IF
Sungwoo, Lim
I tried to compile below code on MCL, but seems 'find-all-if' function
is no longer used? It is not mentioned in HyperSpec online version,
instead I found the 'find-if' function.
Does 'find-all-if' is same as 'find-if' or is there something else?
Thanks for your help.
Sungwoo
(defun consistent-labelings (vertex)
"Return the set of labelings that are consistent with neighbors."
(let ((neighbor-labels
(mapcar #'(lambda (neighbor) (labels-for neighbor vertex))
(vertex-neighbors vertex))))
(find-all-if
#'(lambda (labeling)
(every #'member (mapcar #'reverse-label labeling)
neighbor-labels))
(vertex-labelings vertex))))
Sungwoo, Lim
<sun...@cad.strath.ac.uk> wrote:
I found the answer.
The 'find-all-if' is actually different name of 'remove-if-not' as
(setf (symbol-function 'find-all-if) #'remove-if-not)
It was in the page 100 of Norvig's Paradigms of AI.
Sungwoo
Pierre R. Mai
> remove-if-not and delete-if-not are deprecated. You should probably use
> instead:
>
> (remove-if (complement
> #'(lambda (labeling)
> (every #'member (mapcar #'reverse-label labeling)
> neighbor-labels)))
> (vertex-labelings vertex))
>
> Of course, if you choose to do so, you will not be able to setf a symbol
> function as easily...
While the -if-not functions are officially deprecated, there seems to
be a growing consensous in the user community that this was in fact a
bit premature, given that remove-if-not/delete-if-not are the natural
way to filter a sequence based on a predicate. With this growing
consensous and the reluctance to change the core standard in mind, it
seems to me very unlikely that the *-if-not functions will go away.
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Erik Naggum
| remove-if-not and delete-if-not are deprecated.
The user community has disagreed with that suggestion. *-if-not will
survive. test-not arguments are probably _not_ going to survive.
#:Erik
--
"When you are having a bad day and it seems like everybody is trying
to piss you off, remember that it takes 42 muscles to produce a
frown, but only 4 muscles to work the trigger of a good sniper rifle."
-- Unknown
Erik Naggum
| With this growing consensous and the reluctance to change the core
| standard in mind, it seems to me very unlikely that the *-if-not
| functions will go away.
And if they go away from the standard, it will take somebody who has
implemented them a few millisecond to move them into a different
package that all Common Lisp programmers will probably include on
their package use lists. This is quite different from the :test-not
arguments, which will cause an error once removed. It is therefore
likely that even if the standard removes *-if-not, they will not go
away in real life, but if it removes :test-not, it will go away. It
would be foolish for a standard to do something that it knows will be
countered by the user community, so in all likelihood, operators in
the standard today will never go away.
Sunil Mishra
> * "Pierre R. Mai" <pm...@acm.org>
> | With this growing consensous and the reluctance to change the core
> | standard in mind, it seems to me very unlikely that the *-if-not
> | functions will go away.
>
> And if they go away from the standard, it will take somebody who has
> implemented them a few millisecond to move them into a different
> package that all Common Lisp programmers will probably include on
> their package use lists. This is quite different from the :test-not
> arguments, which will cause an error once removed. It is therefore
> likely that even if the standard removes *-if-not, they will not go
> away in real life, but if it removes :test-not, it will go away. It
> would be foolish for a standard to do something that it knows will be
> countered by the user community, so in all likelihood, operators in
> the standard today will never go away.
>
> #:Erik
OK, fair enough. It did strike me as odd that the standard chose to
eliminate redundancy to this extent with the *-if and *-if-not
functions, while not bothering with redundant functions elsewhere (for
instance, car/first). I do believe the *-if-not make for a simpler
construction than using complement everywhere. And they certainly aren't
as confusing as :test-not arguments, given that :test-not also has the
potential for producing conflicts with the use of :test. (Even if the
standard specifies away the confusion, an inexperienced programmer migth
be caught off guard.)
Sunil
Sunil Mishra
> In article <071220001234283277%sun...@cad.strath.ac.uk>, Sungwoo, Lim
> <sun...@cad.strath.ac.uk> wrote:
>
>
>> Hello,
>>
>> I tried to compile below code on MCL, but seems 'find-all-if' function
>> is no longer used? It is not mentioned in HyperSpec online version,
>> instead I found the 'find-if' function.
>> Does 'find-all-if' is same as 'find-if' or is there something else?
>> Thanks for your help.
>> Sungwoo
>>
>> (defun consistent-labelings (vertex)
>> "Return the set of labelings that are consistent with neighbors."
>> (let ((neighbor-labels
>> (mapcar #'(lambda (neighbor) (labels-for neighbor vertex))
>> (vertex-neighbors vertex))))
>> (find-all-if
>> #'(lambda (labeling)
>> (every #'member (mapcar #'reverse-label labeling)
>> neighbor-labels))
>> (vertex-labelings vertex))))
>
>
> I found the answer.
> The 'find-all-if' is actually different name of 'remove-if-not' as
> (setf (symbol-function 'find-all-if) #'remove-if-not)
>
> It was in the page 100 of Norvig's Paradigms of AI.
>
> Sungwoo
remove-if-not and delete-if-not are deprecated. You should probably use
instead:
(remove-if (complement
#'(lambda (labeling)
(every #'member (mapcar #'reverse-label labeling)
neighbor-labels)))
(vertex-labelings vertex))
Of course, if you choose to do so, you will not be able to setf a symbol
function as easily...
S
Sungwoo, Lim
<sunil....@everest.com> wrote:
>
> remove-if-not and delete-if-not are deprecated. You should probably use
> instead:
>
> (remove-if (complement
> #'(lambda (labeling)
> (every #'member (mapcar #'reverse-label labeling)
> neighbor-labels)))
> (vertex-labelings vertex))
>
> Of course, if you choose to do so, you will not be able to setf a symbol
> function as easily...
>
> S
Hmm... I see.
I can't compare the both result yet, but I will try both.
Thanks, =)
Sungwoo
Kent M Pitman
> OK, fair enough. It did strike me as odd that the standard chose to
> eliminate redundancy to this extent with the *-if and *-if-not
> functions, while not bothering with redundant functions elsewhere (for
> instance, car/first).
Well, to clarify, the sense of redundancy here is very different.
In the case of -if and -if-not we are talking about things on the same
conceptual/abstraction level.
In the case of CAR vs FIRST, you're talking about two different abstraction
levels. FIRST is a friend of REST and is about lists. CAR is a friend of
CDR and is about conses. That a cons is a list is purely an implementation
detail. One might change the implementation (risking the ire of the
community) of lists to be something else, and FIRST/REST would be changed
while CAR/CDR would be left behind. Good coding style, one might say,
tries to use these names in a way that is consistent with protecting code
against such change... though pragmatically there is little risk of such a
change ever happening.
Back on -if and -if-not, though, I think the view of them as redundant
was misguided, and that's why X3J13 is probably backing off. The fact
is that English and the human brain come into play in some odd ways
here. I once wrote a theorem prover with a natural-language-like
front end that let you say things like "Show p implies q." or "Show
that if p implies q and p then q." and stuff like that. What I
quickly learned is that "x implies y" is not redundant with "if x then
y" but rather is a "kludge" in the natural language to allow you to
embed more nesting into a language (English) that is inherently
crippled in its ability to gracefully handle nesting. It's "easier" to
understand "if p implies q then q" than "if if p then q then q". That's
just a fact of how your brain works. Short term memory being what it is,
the use of unrelated terms avoids mental collisions that make it hard to
remember where you were. Likewise, I've seen people claim (and it seems
plausible) that "unless" is just mechanically easier for the human brain
to understand than "when not", and therefore is not "redundant" but is
a way of hiding nots, keeping the overall number of nots in an expression
to a tractable number, since it's easy to exceed the nesting depth of nots
that the human brain can handle without desending into uncontrollable
laughter (or perhaps tears). Proponents of the foo-if-not functions claim,
and I have no reason to disbelieve them, that they think about them not as
"foo-if (complement test)" but as an atomic thing more akin to "foo-unless",
so that the fact of the change from a hyphenated not to a non-hyphenated
not introduces non-trivial cognitive overhead. This isn't as silly as it
sounds. (foo-if-not #'bar) basically involves only two terms, the meaning
of which is probably deeply compiled into one's brain. On the other hand,
(complement #'bar) creates a new conceptual thing that one has to learn
separately and then combine with a function whose meaning is usually also
complementary, creating the need to mentally cancel two nots until one gets
to a primitive understanding that is probably not far from the
foo-if-not #'bar that they would like to have started with. It's a common
misconception in newbie programmers that (if (not x) b a) will
be slower than (if x a b); it takes some sophistication to understand that
although NOT is a function and not a special form, its true meaning is
really much more special-form-like in that compiled code dealing with it
will often flip things around and gain access to things that have no overt
name but are logically orthogonal hidden operations that are just as primitive
as the primitive-looking ones you can get without the use of not.
Which is all to say that I have seen the error of my ways and have
recanted my former deathwish for the -if-not functions... and that I don't
want first/rest to go away either ... but for completely different reasons.