home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / lisp / 2948 < prev    next >
Encoding:
Internet Message Format  |  1992-11-24  |  2.1 KB
  1. Xref: sparky comp.lang.lisp:2948 comp.lang.lisp.mcl:1689
  2. Newsgroups: comp.lang.lisp,comp.lang.lisp.mcl
  3. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!agate!boulder!cambridge.apple.com!apple!usc!sol.ctr.columbia.edu!ira.uka.de!sbusol.rz.uni-sb.de!coli.uni-sb.de!mp-mac10.coli.uni-sb.de!espen
  4. From: espen@coli.uni-sb.de (Espen J. Vestre)
  5. Subject: Re: remove
  6. Message-ID: <722574756.14458@news.Colorado.EDU>
  7. Lines: 26
  8. Sender: news
  9. Organization: Computerlinguistik, Universitaet des Saarlandes
  10. References: <HALTRAET.92Nov20091121@monsun.si.no>
  11. Distribution: co
  12. Date: 23 Nov 92 16:59:34 GMT
  13. Approved: news
  14. X-Note1: mail msgid was <1er2lmINNl0a@coli-gate.coli.uni-sb.de>
  15. X-Note2: message-id generated by recnews
  16. Lines: 26
  17.  
  18. In article <SIMON.92Nov23130108@liasg2.epfl.ch> Simon Leinen,
  19. simon@lia.di.epfl.ch writes:
  20. >Espen is correct in that Hallvard's REMOVE variant isn't
  21. >tail-recursive and may therefore cause problems with long lists.  One
  22. >could code an iterative tail-preserving version (which might be slower).
  23. >
  24. >But I did some benchmarking on Sun-4s under Allegro and CMU CL, and even
  25. >on longish lists (like 1000 elements or so), Hallvard's FASTER-REMOVE
  26. >performed better on the whole than the system-provided REMOVE versions.
  27. >I would bet that at least 90% of the uses of REMOVE would benefit from
  28. >using FASTER-REMOVE.
  29.  
  30. Yes, especially if you take into account that if you're using very long
  31. lists as your data structures, you are probably using the wrong kind of
  32. data structure.
  33. I guess a lot of programs might benefit even more from _memoizing_ the
  34. remove function, i.e. if the program is using remove to filter the same
  35. list again and again, it would benefit from knowing that, e.g., a given
  36. value isn't present in that list at all.
  37. --------------------------------------------------------------
  38. Espen J. Vestre,                          espen@coli.uni-sb.de
  39. Universitaet des Saarlandes,        
  40. Computerlinguistik, Gebaeude 17.2 
  41. Im Stadtwald,                          tel. +49 (681) 302 4501
  42. D-6600 SAARBRUECKEN, Germany           fax. +49 (681) 302 4351
  43. --------------------------------------------------------------
  44.