httpc 6 > (search "<table" *http-payload* :test #'char-equal :start2 0)
1524
httpc 7 > (search "<table" *http-payload* :test #'string-equal :start2 0)
1524
Hmmm. I'm confused as to why I should use one or the other.
CLHS just says:
test---a designator for a function of two arguments that returns a
generalized boolean.
CLTL2 doesn't seem to hold any more information as to why
char-equal should work (as string-equal does) in the case
of sequences which is why I'm using search and not position.
Is this implementation specific?
FWIW: OSX LW 5.0.2 (intel)
Many thanks
--
JFB
In article <·······················@news.aaisp.net.uk>,
verec <·····@mac.com> wrote:
> httpc 6 > (search "<table" *http-payload* :test #'char-equal :start2 0)
> 1524
>
> httpc 7 > (search "<table" *http-payload* :test #'string-equal :start2 0)
> 1524
>
> Hmmm. I'm confused as to why I should use one or the other.
>
> CLHS just says:
>
> test---a designator for a function of two arguments that returns a
> generalized boolean.
>
> CLTL2 doesn't seem to hold any more information as to why
> char-equal should work (as string-equal does) in the case
> of sequences which is why I'm using search and not position.
>
> Is this implementation specific?
>
> FWIW: OSX LW 5.0.2 (intel)
>
> Many thanks
> --
> JFB
See http://www.lispworks.com/documentation/HyperSpec/Body/f_stgeq_.htm#string-equal
CHAR-EQUAL is correct.
STRING-EQUAL will also work, since characters are
string designators.
(STRING-EQUAL #\a #\b) = (STRING-EQUAL (string #\a) (string #\b))
--
http://lispm.dyndns.org/
From: Kent M Pitman
Subject: Re: char-equal vs string-equal in search
Date:
Message-ID: <uzlvjwy05.fsf@nhplace.com>
Rainer Joswig <······@lisp.de> writes:
> In article <·······················@news.aaisp.net.uk>,
> verec <·····@mac.com> wrote:
>
> > httpc 6 > (search "<table" *http-payload* :test #'char-equal :start2 0)
> > httpc 7 > (search "<table" *http-payload* :test #'string-equal :start2 0)
> > Hmmm. I'm confused as to why I should use one or the other.
>
> CHAR-EQUAL is correct.
and should be preferred.
> STRING-EQUAL will also work,
but might be slower and is not what I nor probably anyone would recommend.
> since characters are string designators.
> (STRING-EQUAL #\a #\b) = (STRING-EQUAL (string #\a) (string #\b))
Kent M Pitman <······@nhplace.com> writes:
> Rainer Joswig <······@lisp.de> writes:
>
>> In article <·······················@news.aaisp.net.uk>,
>> verec <·····@mac.com> wrote:
>>
>> > httpc 6 > (search "<table" *http-payload* :test #'char-equal :start2 0)
>> > httpc 7 > (search "<table" *http-payload* :test #'string-equal :start2 0)
>> > Hmmm. I'm confused as to why I should use one or the other.
>>
>> CHAR-EQUAL is correct.
>
> and should be preferred.
>
>> STRING-EQUAL will also work,
>
> but might be slower and is not what I nor probably anyone would recommend.
Except to illustrate:
(defun phoney-search (s1 s2 &rest keys)
(apply #'search s1 s2 :test #'string-equal keys))
(phoney-search "is" "lisp")
=> 1
(phoney-search '(india sierra) '(lima india sierra papa))
=> 1
---Vassil.
--
Bound variables, free programmers.
verec <·····@mac.com> writes:
> httpc 6 > (search "<table" *http-payload* :test #'char-equal :start2 0)
> 1524
>
> httpc 7 > (search "<table" *http-payload* :test #'string-equal :start2 0)
> 1524
>
> Hmmm. I'm confused as to why I should use one or the other.
Laziness or precision, it's up to you.
(search '(#\a "b" c) "toto abc titi" :test (function string-equal)) --> 5
(search '"abc" "toto abc titi" :test (function char-equal)) --> 5
(search '"abc" "toto abc titi" :test (function equalp)) --> 5
(search '(#\a 1 a) #(#\a 1.0 :a 1 "a" #\a 1 a a) :test (function equalp)) --> 5
When you know you'll be comparing only characters you may use
char-equal, it could be faster, and if you get non-character input,
it'd signal an error.
If you wanted to compare somethings that may be anything, you'd use equal.
If you want to compare string designators, and a character is a
designator for a string containing only this character, you can use
string-equal.
So the meaning is clear:
equalp => I want anything, for strings or characters I don't care the case.
string-equal => I want string designators, I don't care the case.
char-equal => I want characters, I don't care the case.
Now, if you wanted characters and you'd say string-equal or equalp,
it'd still work, but it'd be less precise, you'd get less bug reports,
and the compiler would be less able to optimize. Up to you.
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
On 2008-01-05 23:51:06 +0000, Pascal Bourguignon <···@informatimago.com> said:
> verec <·····@mac.com> writes:
>
>> httpc 6 > (search "<table" *http-payload* :test #'char-equal :start2 0)
>> 1524
>>
>> httpc 7 > (search "<table" *http-payload* :test #'string-equal :start2 0)
>> 1524
>>
>> Hmmm. I'm confused as to why I should use one or the other.
>
> Laziness or precision, it's up to you.
>
> (search '(#\a "b" c) "toto abc titi" :test (function
> string-equal)) --> 5
> (search '"abc" "toto abc titi" :test (function
> char-equal)) --> 5
> (search '"abc" "toto abc titi" :test (function
> equalp)) --> 5
> (search '(#\a 1 a) #(#\a 1.0 :a 1 "a" #\a 1 a a) :test (function
> equalp)) --> 5
>
> When you know you'll be comparing only characters you may use
> char-equal, it could be faster, and if you get non-character input,
> it'd signal an error.
>
> If you wanted to compare somethings that may be anything, you'd use equal.
>
> If you want to compare string designators, and a character is a
> designator for a string containing only this character, you can use
> string-equal.
>
>
> So the meaning is clear:
>
> equalp => I want anything, for strings or characters I don't care
> the case.
> string-equal => I want string designators, I don't care the case.
> char-equal => I want characters, I don't care the case.
>
>
> Now, if you wanted characters and you'd say string-equal or equalp,
> it'd still work, but it'd be less precise, you'd get less bug reports,
> and the compiler would be less able to optimize. Up to you.
Thanks.
I had already made up my mind as to whether I wanted xxx= vs xxx-equal
(with xxx being either of char or string). I want xxx-equal.
The question really was about char-xzy vs string-xyz.
httpc 23 > (position #\a "bac")
1
httpc 24 > (position "a" "bac")
nil
httpc 25 > (position #\a "bac" :test #'char-equal)
1
httpc 26 > (position #\a "bAc" :test #'char-equal)
1
httpc 27 > (position "a" "bAc" :test #'char-equal)
"a" is not of type character.
httpc 28 > (position "a" "bAc" :test #'string-equal)
1
httpc 29 > (position "aC" "bAc" :test #'string-equal)
nil
OK. I see that position does not work for strings (sequence)
So let's use search instead. Which kind of made sense if I
understand position as finding an item which is not a sequence
within a sequence, and search as finding a subsequence within
a sequence.
Which kind of implied to my mind that the predicate used to
test for presence ought to match the kind (item vs sequence)
of stuff I am looking for, given that in both cases I am looking
_within_ a sequence.
So, even though I get an idea that deep down in the bowels of
search, a "byte by byte" comparison is performed, I was inclined
to use string-equal rather than char-equal, because I am using
search and not position.
It is the fact that both char-equal and string-equal work in search
that puzzles me.
httpc 30 > (search "aC" "bAc" :test #'string-equal)
1
httpc 31 > (search "aC" "bAc" :test #'char-equal)
1
--
JFB
verec <·····@mac.com> writes:
> [...]
> OK. I see that position does not work for strings (sequence)
> So let's use search instead. Which kind of made sense if I
> understand position as finding an item which is not a sequence
> within a sequence, and search as finding a subsequence within
> a sequence.
>
> Which kind of implied to my mind that the predicate used to
> test for presence ought to match the kind (item vs sequence)
> of stuff I am looking for, given that in both cases I am looking
> _within_ a sequence.
What about sequences within sequences?
(search #("def" "ghi") #("abc" "def" "GHI" "klm") :test (function string-equal))
Otherwise, you may have not noticed the power of :TEST:
(search " good " "Some nice words and some weed and stuff."
:test (lambda (a b) ; both vowel or both consonant
(or (and (find a "aeiouy") (find b "aeiouy"))
(and (not (find a "aeiouy")) (not (find b "aeiouy"))))))
> So, even though I get an idea that deep down in the bowels of
> search, a "byte by byte" comparison is performed, I was inclined
> to use string-equal rather than char-equal, because I am using
> search and not position.
Try this:
(defun se (a b) (string-equal a b))
(trace se)
(search "def" "abcdefghi" :test (function se))
> It is the fact that both char-equal and string-equal work in search
> that puzzles me.
Not only them, any function taking two arguments would work for :TEST
in SEARCH (each meaning its own thing).
http://www.lispworks.com/documentation/HyperSpec/Body/17_ba.htm
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/