I am running lispworks personnal 4.2.0 under windows NT4
When using delete-if as follows I get unexpected results
(delete-if #'(lambda (Keyword) (member keyword stopword_List :test #'string-equal)) Allkeywords_List)
Allkeywords_List is a simple list of 445 strings
Stopword_List is a simple list of 2406 strings
evaluation returns a list of length 417 which is what I want
however Allkeywords_List is modified to a list of length 421
The errant four strings which were not removed are "00s" "10s" "1660s" "1790s"
They occupy the first four postitions on the modified list and are otherwise
unexeptional.
If I have to use delete-if in the same way I would remove-if (by a setq of the
returned result to replace my Allkeywords_list), including it in common lisp
only seems to add a potential for error.
Having to learn words like cdr is trivial but obscure behavior like this of an
apparently attractive straightforward function is a real worry.
Is it my fault, have I hit a bug or do I grasp even less than the one percent
I thought I had?
Is there a list of the functions which, like the delete family, do not behave themselves?
---
riebauld
~~~~~~~~~~~~~~~~~~~~~
This message was posted via one or more anonymous remailing services.
The original sender is unknown. Any address shown in the From header
is unverified.
riebauld wrote:
> I am running lispworks personnal 4.2.0 under windows NT4
> When using delete-if as follows I get unexpected results
>
> (delete-if #'(lambda (Keyword) (member keyword stopword_List :test #'string-equal)) Allkeywords_List)
>
> Allkeywords_List is a simple list of 445 strings
> Stopword_List is a simple list of 2406 strings
> evaluation returns a list of length 417 which is what I want
> however Allkeywords_List is modified to a list of length 421
>
> The errant four strings which were not removed are "00s" "10s" "1660s" "1790s"
> They occupy the first four postitions on the modified list and are otherwise
> unexeptional.
>
> If I have to use delete-if in the same way I would remove-if (by a setq of the
> returned result to replace my Allkeywords_list), including it in common lisp
> only seems to add a potential for error.
> Having to learn words like cdr is trivial but obscure behavior like this of an
> apparently attractive straightforward function is a real worry.
>
> Is it my fault, have I hit a bug or do I grasp even less than the one percent
> I thought I had?
A little of the last, but also you are in what I call the Uncertainty
Zone. It happens to me, too. Until I develop confidence in a new toy,
especially a toy that is new to the world and not just new to me,
whenever anything goes wrong I throw up my hands and scream "This thing
is crap!". Then I go on a newsgroup or support forum and get my butt
kicked for not RTFM.
What has happened here is merely that you have stumbled onto possibly
the most common newby land-mine, the behavior of destructive functions
and especially the need in many uses to capture the return value.
Now relax and get back to work. And RTFM. :)
> Is there a list of the functions which, like the delete family, do not behave themselves?
watch out for the letter "n" <g>. as in "nconc" and "mapcan". but you
knew about destructive operations, so I guess knowing which are
destructive is not the problem. ya just gotta slow down and stare at
destructive operations a little harder.
The Lisp FAQ might be a shortcut for you since most newby land-mines are
in there somewhere:
http://www-2.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/top.html
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
riebauld <········@sorry.if.it.comes.out.anonymous> writes:
> I am running lispworks personnal 4.2.0 under windows NT4
> When using delete-if as follows I get unexpected results
>
> (delete-if #'(lambda (Keyword) (member keyword stopword_List :test #'string-equal)) Allkeywords_List)
>
> Allkeywords_List is a simple list of 445 strings
> Stopword_List is a simple list of 2406 strings
> evaluation returns a list of length 417 which is what I want
> however Allkeywords_List is modified to a list of length 421
>
> The errant four strings which were not removed are "00s" "10s"
> "1660s" "1790s" They occupy the first four postitions on the
> modified list and are otherwise unexeptional.
>
> If I have to use delete-if in the same way I would remove-if (by a
> setq of the returned result to replace my Allkeywords_list),
> including it in common lisp only seems to add a potential for error.
>
> Having to learn words like cdr is trivial but obscure behavior
> like this of an apparently attractive straightforward function is a
> real worry.
>
> Is it my fault, have I hit a bug or do I grasp even less than the
> one percent I thought I had?
>
> Is there a list of the functions which, like the delete family, do
> not behave themselves?
You have already found the reason for your confusion: DELETE-IF is to
be used _exactly_ like REMOVE-IF, i.e. you are supposed to use the
value returned by DELETE-IF and not to rely on any side-effects. You
cannot be sure that Allkeywords_List will be as you expected after
calling DELETE-IF.
The only difference between the two functions is that DELETE-IF _may_
modify the sequence for performance reasons, i.e. you cannot rely on
your argument being the same after calling DELETE-IF. With REMOVE-IF
you can. Common Lisp has a couple of function pairs like these
(destructive vs. non-destructive). I think it's a good recommendation
for beginners to avoid the destructive versions and only use them if
you have identified performance bottlenecks.
This is neither 'obscure behaviour' nor 'a potential for error' - the
behaviour of these functions is clearly defined in the ANSI
standard. Common Lisp was designed to empower programmers - it was not
intended to foster "Learn CL in 24 hours" books.
Cheers,
Edi.
PS: Variable names like "stopword_List" or "Allkeywords_List" look
ugly to most Lisp programmers. You should stick to the usual
conventions and name them like "stopword-list" and
"allkeywords-list".
Edi Weitz wrote:
> (destructive vs. non-destructive). I think it's a good recommendation
> for beginners to avoid the destructive versions and only use them if
> you have identified performance bottlenecks.
(my-2)
=> "Certainly if just playing around, but before they get down to Actual
Coding they should have the issue under control.
First of all, hell, it's not /that/ hard to know when you can safely
whack a structure (or to remember to grab it on the return).
Second, we don't need newbies running around saying, 'Kenny lied! Lisp
is still slow!!'"
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton wrote:
> Second, we don't need newbies running around saying, 'Kenny lied! Lisp
> is still slow!!'"
> :)
i am just wondering, is it a common spirit here?
BTW,
1) why "I/O is soo slow" thread is long enough already.
but only a one real solution: FFI.
2) Quite interesting: CL has nothing to do with this issue. There is
no shame for CL itself. It is rather a small note on status quo
of current *implementations*.
Am i wrong?
2Kenny: feel free to send all flames/emotions directly to me
(this group is not dedicated for my person). Thank you.
--
Valery
On Sun, Jul 27, 2003 at 08:51:05PM +0200, Valery A.Khamenya wrote:
> BTW,
> 1) why "I/O is soo slow" thread is long enough already.
> but only a one real solution: FFI.
Uh, no. Didn't you read the thread? You can achieve near-C speeds,
writing to a file, without leaving ANSI CL. A simple change of the
buffering scheme for *STANDARD-OUTPUT* in CMUCL allowed the same
performance to stdout, as well. FFI is not necessary.
> 2) Quite interesting: CL has nothing to do with this issue. There is
> no shame for CL itself. It is rather a small note on status quo
> of current *implementations*.
If you mean the way buffering was set-up by default on
*STANDARD-OUTPUT*, consider that there may very well be good reasons to
have :LINE buffering normally (such as when printing output to an
interactive user).
> Am i wrong?
Yes.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Valery A.Khamenya wrote:
> Kenny Tilton wrote:
>
>> Second, we don't need newbies running around saying, 'Kenny lied! Lisp
>> is still slow!!'"
>> :)
>
>
> i am just wondering, is it a common spirit here?
No, but it is easy to cons up a storm without realizing it. Even I
occasionally slip up and stick an innocent little bit of consing in
something which runs a kazillion times. So I think even a newbie should
learn that list processing, as cool as it is to have it built into the
language, is not a free lunch. Power to be abused, not abused and all that.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
On 8453 day of my life Valery A. Khamenya wrote:
> 2) Quite interesting: CL has nothing to do with this issue. There is
> no shame for CL itself. It is rather a small note on status quo
> of current *implementations*.
>
> Am i wrong?
It's impossible to create fast programs with some languages. For
example, nobody use Perl for numeric computations, because it is
"almost typeless" with no choice. And nobody use pure Scheme for same
proposes (Bigloo is fast if you use extensions). So, it depends on
language. So, question about "fastness" of language is reasonable.
But another question arises: do we always need fast languages? :)
Though I'd like to have high-optimizing Lisp compiler (numeric code
faster than Fortran! I wish time of S-1 Lisp would come back :)
--
Ivan Boldyrev
"Assembly of Japanese bicycle require great peace of mind."
Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
> For example, nobody use Perl for numeric computations, because it is
> "almost typeless" with no choice.
If only this were true. Alas, the above should read, "... nobody
should use Perl for numeric computations ...".
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On 8454 day of my life Thomas F. Burdick wrote:
> Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
>
>> For example, nobody use Perl for numeric computations, because it is
>> "almost typeless" with no choice.
>
> If only this were true. Alas, the above should read, "... nobody
> should use Perl for numeric computations ...".
Hush!!! Don't tell anyone!!! It's the only one way to make boss to
buy new hardware :)
--
Ivan Boldyrev
Outlook has performed an illegal operation and will be shut down.
If the problem persists, contact the program vendor.
{{Date: 27 Jul 2003 13:32:34 -0000
From: riebauld <········@sorry.if.it.comes.out.anonymous>
(delete-if #'... Allkeywords_List)
Allkeywords_List is modified to a list of length 421}}
No, Allkeywords_List is *destroyed* by the operation, or that's how you
should think about it. It's right there in the documentation for
delete-if. Whenever you read the documentation for a function, and see
the word destroyed, or the word destructively, or any form of those
words referring to one of the arguments to the function, you must *not*
expect the structure of that argument to be in any way valid after the
operation. If it's going to bother you to look at it, you should
immediately (setq Allkeywords_List nil) after the operation to avoid
temptation. For example, look at the function sort, which destructively
sorts a list.
If for some reason you still want the original argument to be around
unchanged after the operation, use the non-destructively version of the
function if available, else call copy-list or other appropriate
structure-copying function on the argument while passing it to the
destructive function. In your case, you should do:
(remove-if #'... Allkeywords_List)
If, more commonly, you want the result from the function to be the same
as the new value of the destroyed argument, you need to set the place
to the returned value, i.e. in your case you should do:
(setq Allkeywords_List (delete-if #'... Allkeywords_List))
However based on the name of your variable, the name would no longer
match the actual contents there. So in your case use remove-if instead.
By the way, if you don't care about preserving the original ordering,
set-difference would do what you want.