Hi all,
How can I remove an item of specific position from a list?
e.g.
I want to remove the 6th item from '(1 2 1 2 1 2 1 2 1 2 1 2)
How can this be done?
Thanks in advance!
Regards,
Try a function (remove-if)
cg-user:: (remove-if #'(lambda (x) (= (position x '(1 2 3 4 5 6 7 8)) 3))
'(1 2 3 4 5 6 7 8))
(1 2 3 5 6 7 8)
cheers
K Min
Dav <·········@hongkong.com> wrote in message news:<·················@hongkong.com>...
> Hi all,
>
> How can I remove an item of specific position from a list?
>
> e.g.
> I want to remove the 6th item from '(1 2 1 2 1 2 1 2 1 2 1 2)
>
> How can this be done?
>
> Thanks in advance!
>
> Regards,
"Coby Beck" <·····@mercury.bc.ca> writes:
> (defun remove-nth (list n)
> (let ((index -1))
> (remove-if #'(lambda (elt)
> (declare (ignore elt))
> (= n (incf index)))
> list)))
Is REMOVE-IF TEST SEQUENCE :COUNT NIL guaranteed to give
elements to TEST in the same order as they are in SEQUENCE?
I don't see why an implementation would do otherwise, though.
* Kalle Olavi Niemitalo <···@iki.fi>
| Is REMOVE-IF TEST SEQUENCE :COUNT NIL guaranteed to give
| elements to TEST in the same order as they are in SEQUENCE?
| I don't see why an implementation would do otherwise, though.
I think this case is fairly obvious (i.e., I would complain if anyone
were "smart" and did something else), but it is less obvious that
supplying :from-end t :count nil will call the test on elements in the
reverse order, since from-end is specified to have an effect only when
count is non-nil. All implementations that I can test this on, however,
do call test in the reverse order. [I used this simple call to see the
effect: (remove-if #'print '(1 2 3 4) :from-end t).]
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
"Dav" <·········@hongkong.com> wrote in message
······················@hongkong.com...
>
> Geoffrey Summerhayes wrote:
> >
> >
> > (remove-if (lambda (x) t) list :start position :count 1)
> >
>
> Oh yeah... I have to change it to:
>
> (remove-if #'(lambda (x) t) list :start position :count 1)
>
> to make it works ;-)
Did you try it both ways?
---------
Geoff
* Dav <·········@hongkong.com>
| Oh yeah... I have to change it to:
|
| (remove-if #'(lambda (x) t) list :start position :count 1)
|
| to make it works ;-)
Which version of which Common Lisp system are you using?
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
"synthespian" <···········@uol.com.br> wrote in message
·······································@uol.com.br...
> On Fri, 19 Apr 2002 00:23:48 -0300, Geoffrey Summerhayes wrote:
> > (remove-if (lambda (x) t) list :start position :count 1)
> >
> > ---------
> > Geoff
>
> Where did you specify that you wanted the 6th position here?
>
I didn't, it's a generic solution with two unknowns.
--------
Geoff
Uh, no.
Tim
Hint: try your approach on the OP's sample data.
Tim
On 18 Apr 2002 16:27:13 -0700, Kyongho Min <···········@aut.ac.nz> wrote:
>Try a function (remove-if)
>
>cg-user:: (remove-if #'(lambda (x) (= (position x '(1 2 3 4 5 6 7 8)) 3))
> '(1 2 3 4 5 6 7 8))
>(1 2 3 5 6 7 8)
>
>cheers
>
>K Min
>
>Dav <·········@hongkong.com> wrote in message news:<·················@hongkong.com>...
>> Hi all,
>>
>> How can I remove an item of specific position from a list?
>>
>> e.g.
>> I want to remove the 6th item from '(1 2 1 2 1 2 1 2 1 2 1 2)
>>
>> How can this be done?
>>
>> Thanks in advance!
>>
>> Regards,
"Dav" <·········@hongkong.com> wrote in message
······················@hongkong.com...
> Hi all,
>
> How can I remove an item of specific position from a list?
>
> e.g.
> I want to remove the 6th item from '(1 2 1 2 1 2 1 2 1 2 1 2)
>
> How can this be done?
>
> Thanks in advance!
>
> Regards,
You've seen one approach already but if you desire something that is
non-destructive (ie leaves its input argument intact) try this:
(defun remove-nth (list n)
(loop for elt in list
for i upfrom 0
unless (= i n)
collect elt))
or for those who hate loop:
(defun remove-nth (list n)
(let ((index -1))
(mapcan #'(lambda (elt)
(if (= n (incf index))
nil
(list elt)))
list)))
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> You've seen one approach already but if you desire something that is
> non-destructive (ie leaves its input argument intact) try this:
> (defun remove-nth (list n)
> (loop for elt in list
> for i upfrom 0
> unless (= i n)
> collect elt))
>
> or for those who hate loop:
> (defun remove-nth (list n)
> (let ((index -1))
> (mapcan #'(lambda (elt)
> (if (= n (incf index))
> nil
> (list elt)))
> list)))
Good grief! Why all that hair?
(defun remove-nth (list n)
(if (= n 0)
(cdr list)
(cons (car list) (remove-nth (cdr list) (- n 1)))))
Thomas
"Thomas Bushnell, BSG" <·········@becket.net> wrote in message
···················@becket.becket.net...
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
>
> > You've seen one approach already but if you desire something that is
> > non-destructive (ie leaves its input argument intact) try this:
>
> > (defun remove-nth (list n)
> > (loop for elt in list
> > for i upfrom 0
> > unless (= i n)
> > collect elt))
> >
> > or for those who hate loop:
> > (defun remove-nth (list n)
> > (let ((index -1))
> > (mapcan #'(lambda (elt)
> > (if (= n (incf index))
> > nil
> > (list elt)))
> > list)))
>
> Good grief! Why all that hair?
>
> (defun remove-nth (list n)
> (if (= n 0)
> (cdr list)
> (cons (car list) (remove-nth (cdr list) (- n 1)))))
>
> Thomas
I guess I never think of recursion when the problem is iterative. Your
solution does have the advantage of "quiting" once it finds its target.
So many ways to skin such a simple cat...
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> I guess I never think of recursion when the problem is iterative. Your
> solution does have the advantage of "quiting" once it finds its target.
I'm not sure what you mean by "the problem is iterative". Problems
aren't iterative or recursive, solutions are. You might, however, say
that a problem is iterative is the cleanest or simplest solution is
iterative. This depends in part on what language you are using, but
it seems clear to me that in lisp the problem is recursive, by this
test.
However, the other suggested solutions are generally not iterative:
they depend, for example, on collection functions, which are
themselves most naturally written in a recursive style.
On 18 Apr 2002 23:34:44 -0700, Thomas Bushnell, BSG <·········@becket.net>
wrote:
>"Coby Beck" <·····@mercury.bc.ca> writes:
>
>> I guess I never think of recursion when the problem is iterative. Your
>> solution does have the advantage of "quiting" once it finds its target.
>
>I'm not sure what you mean by "the problem is iterative". Problems
>aren't iterative or recursive, solutions are. You might, however, say
>that a problem is iterative is the cleanest or simplest solution is
>iterative. This depends in part on what language you are using, but
>it seems clear to me that in lisp the problem is recursive, by this
>test.
>
>However, the other suggested solutions are generally not iterative:
>they depend, for example, on collection functions, which are
>themselves most naturally written in a recursive style.
Perhaps you should "In My Humble Opinion" to that :) I'm not sure what
you mean by "collection functions;" so far we've seen remove-if,
mapcan and the collect clause of the loop macro. collect isn't a
function, it's a keyword designating iterative collection! That is,
collection by holding on to the last cons of the a list and
successively setfing the cdr of it. remove-if might be more nicely
expressed in a recursive style than an iterative one, but no serious
Common Lisp implementation would do it that way because it would risk
overflowing the stack. Ditto mapcan, though it's debatable whether
it's more natural to express that iteratively or recursively. It's
debatable whether it's really "more natural" to write remove-if and
mapcan in a recursive style than in an iterative one when you do have
macros like loop that support iterative collection.
Tim
"Thomas Bushnell, BSG" <·········@becket.net> wrote in message
···················@becket.becket.net...
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
> > I guess I never think of recursion when the problem is iterative. Your
> > solution does have the advantage of "quiting" once it finds its target.
>
> I'm not sure what you mean by "the problem is iterative".
I mean a problem involving a flat list and something to do to/with it.
> Problems
> aren't iterative or recursive, solutions are.
Fair enough.
> You might, however, say
> that a problem is iterative is the cleanest or simplest solution is
> iterative.
I can go with the above if by solution you mean algorithm rather than
program, but I am sure you and i would disagree about "clean" and "simple."
I liked your proposal, but it goes in the "clever" category. ie. it is not a
"natural" approach unless one has studied and prefers to use recursion.
(sorry for all the scare quotes, I'm just acknowledging that I am using a
bunch of loaded terms in the way that suits my point best :)
It is worth noting that the recursive solution and the looping one are not
equivalent in that the loop returns a list that does not share anything with
its input argument. Is that a good thing? Checking the HS for details
about the remove family, while non-destructive they are allowed to share
structure. I think that goes against what I would have expected. ie I can
imagine having run into bugs by taking the result of remove* and thinking it
was now mine to do with as I pleased. I suppose I would have paid more
attention to those issues but my programming has rarely involved any list
surgery.
> This depends in part on what language you are using, but
> it seems clear to me that in lisp the problem is recursive, by this
> test.
I'm not sure why you say this, but i don't see why what language you use
would have any bearing on the nature of the problem.
>
> However, the other suggested solutions are generally not iterative:
> they depend, for example, on collection functions, which are
> themselves most naturally written in a recursive style.
I don't see how you can support that statement. When I use remove-if to
operate on a list, I am not writing recursion. Whatever may happen behind
the scenes is not relevant to the semantics of my expression. IMO...
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Thomas Bushnell, BSG" <·········@becket.net> wrote in message
> ···················@becket.becket.net...
>
> > However, the other suggested solutions are generally not iterative:
> > they depend, for example, on collection functions, which are
> > themselves most naturally written in a recursive style.
>
> I don't see how you can support that statement. When I use remove-if to
> operate on a list, I am not writing recursion. Whatever may happen behind
> the scenes is not relevant to the semantics of my expression. IMO...
The style in which something is written most naturally is something
it's fine to assert for oneself, but lousy data is available about what
'natural' means in this context and in any case, language communities
rarely appeal to such communities when they use these terms.
IMO, it's better to say, "For myself with my experience and training,
xxx feels more natural. And task xxx fortunately yields to such a
technique. This makes me happy."
Since that kind of mode of expression feels stilted, people instead say
sloppy things that sometimes intentionally and sometimes unintentionally,
but mostly needlessly, inflame others.
- - - - -
Curiously, the whole point of the "Scheme way" with addressing
iteration is not to encourage people to think of iterations as
recursions but to encourage people to see certain recursive syntaxes
as being merely a convenient syntax for analyzing iterations. As far
as I recall, Abelson&Sussman refer to these 'tail recursive'
presentations _as_ iterations. As such, I'm not really even sure
whose political party is represented by Thomas's statement above,
which seems to deny the iterative nature of a recursive style; it's
not one of the ordinary political positions of either the CL or Scheme
community, as I understand those positions. That doesn't render it an
invalid position, just a position that puzzles me because I don't know
what point is being made. Maybe I'm just misunderstanding though.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
>
> Curiously, the whole point of the "Scheme way" with addressing
> iteration is not to encourage people to think of iterations as
> recursions but to encourage people to see certain recursive syntaxes
> as being merely a convenient syntax for analyzing iterations. As far
> as I recall, Abelson&Sussman refer to these 'tail recursive'
> presentations _as_ iterations.
I don't want to be a spokesman for the `Scheme way' of thinking
(I'm not sure I know what that is, or that I agree with the dogma),
but I *think* that the `Scheme way' is to consider `recursion' to
be closer to the mathematical sense of defining a function in
terms of itself (or as defining a function as the fixed point of
the self-application of a non-recursive function) whereas `iteration'
is merely a special case of recursion that can be implemented
on a computer without accumulating storage.
> As such, I'm not really even sure
> whose political party is represented by Thomas's statement above,
> which seems to deny the iterative nature of a recursive style; it's
> not one of the ordinary political positions of either the CL or Scheme
> community, as I understand those positions. That doesn't render it an
> invalid position, just a position that puzzles me because I don't know
> what point is being made. Maybe I'm just misunderstanding though.
I don't know what point is being made either.
* "Coby Beck"
| I don't see how you can support that statement.
I thought it was a fairly obvious attempt at the kind trolling we have
become used to from people who have learned Scheme from some textbook
that failed to teach iteration and recursion as morally equivalent.
Sadly, some of those are unable to understand how deeply annoying their
trolling attempts are, convinced as they are of the moral superiority of
recursion and of its "intrinsic elegance" and other such nonsense obvious
to anyone who has not been similarly brainwashed.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
Hi.
"Coby Beck" <·····@mercury.bc.ca> skrev i en meddelelse
···························@news1.calgary.shaw.ca...
>
> "Thomas Bushnell, BSG" <·········@becket.net> wrote in message
> ···················@becket.becket.net...
> > "Coby Beck" <·····@mercury.bc.ca> writes:
> >
> > > I guess
Sorry if I "rush in" to claim, that the right way are, to describe the list
,without the object, then why and how, could be a theoretic issue ,rather than
how this small standard function, shuld be that big a problem ; isn't Lisp about
returning the ansver asked ,esp. in a standard unit like this handeling a symbol
in a list.
Guess a recursive call, yield what's in front, strcat with what's behind ,will
produce a new list as required. This way of "calculating" with members of a
list, as result, wouldn't hazzard the mem. as much today as much as when I first
by ,chance used Lisp. I allway's wantet to learn C++ ,but allway's had trouble
with compilers, more complicatet than Prolog and Pascal . Anyway I think, that
Lisp code, can compile as C ,while you use Lisp syntax, describing functions.
Guess that's implermenting ;))
P.C.
http://d1o111.dk.telia.net/~u139600113/a
P.s.
Sorry if you are having a groupe discussion ,this is just my 2 Kr.
* "Coby Beck" <·····@mercury.bc.ca>
> I guess I never think of recursion when the problem is iterative. Your
> solution does have the advantage of "quiting" once it finds its target.
As long as you don't mind the result sharing structure with the input.
> So many ways to skin such a simple cat...
Here's my go at a properly tail-recursive function returning a list
having no shared structure with the input.
(defun remove-nth (n list &optional (result '()))
(if (null list)
(nreverse result)
(remove-nth (1- n) (cdr list)
(if (= n 0)
result
(cons (car list) result)))))
I think your equivalent loop solution is more readable.
In article <··············@becket.becket.net>,
Thomas Bushnell, BSG <·········@becket.net> wrote:
>
>(defun remove-nth (list n)
> (if (= n 0)
> (cdr list)
> (cons (car list) (remove-nth (cdr list) (- n 1)))))
>
>Thomas
>
or
(defun remove-nth (list n)
(nconc (subseq list 0 n)
(nthcdr (1+ n) list)))
--
---------------------------------------------------------------------
Bernhard Pfahringer, Dept. of Computer Science, University of Waikato
http://www.cs.waikato.ac.nz/~bernhard +64 7 838 4041
Boycott the IEEE for their copyright transfer and export control form