librelist archives

« back to archive

4Clojure #21 and #32 (Spoiler)

4Clojure #21 and #32 (Spoiler)

From:
Andrew Myers
Date:
2013-05-27 @ 13:46
Hi,

I'm working my way through the questions at 4clojure.com, and after
solving the questions I like to have a look at other folks' answers to
see how they compare to mine.

Question 21 is basically to implement the 'nth' function, without
using the built-in nth.  My solution was:

#(loop [c % i %2]
    (if (= 0 i) (first c)
        (recur (rest c) (dec i))))

Then I see some other people suggesting this as an answer:

#((vec %) %2)

Similarly question 32, which is to write a function which duplicates
each element of a sequence, eg:

(= (__ [1 2 3]) '(1 1 2 2 3 3))

I came up with:

#(loop [x % acc []]
    (if (nil? (seq x))
      (seq acc)
      (recur (rest x) (conj (conj acc (first x)) (first x)))))

and other people have suggested:

#(reduce (conj coll %2 %2) [] coll)

which is obviously much nicer than what I had.

So my question is - how do we get to the point where we can get these
really concise answers straight up?  Is it just something that comes
with lots of "practice", or is it a sign that I've missed something
fundamental when this kind of stuff just isn't jumping out at me
immediately?  In particular - is the fact that I tend to go for loop /
recur before anything else indicating I'm still thinking in a more
"imperative" way?

Thanks!

Andrew.

Re: [foray] 4Clojure #21 and #32 (Spoiler)

From:
Ali Baitam
Date:
2013-05-27 @ 15:53
Hi Andrew,
I myself noticed that this tendency in myself to reach to thinking in low
level recursion
loops<http://blog.fogus.me/2011/03/09/recursion-is-a-low-level-operation/>instead
of in a functional and idiomatic way. So I went a step back to
practice the fundamental and core api functions especially map, filter and
reduce and all the Sequence API (the seq section of the cheat sheet). I
went back and started doing myself the examples on clojuredocs (I put them
in a project and going through the examples). That's the foundational step
before tackling 4Clojure.

The more time one dedicates to the early chapter in the book the better.
That's why I am behind on the "foray" schedule.


On Mon, May 27, 2013 at 9:46 AM, Andrew Myers <am2605@gmail.com> wrote:

> Hi,
>
> I'm working my way through the questions at 4clojure.com, and after
> solving the questions I like to have a look at other folks' answers to
> see how they compare to mine.
>
> Question 21 is basically to implement the 'nth' function, without
> using the built-in nth.  My solution was:
>
> #(loop [c % i %2]
>     (if (= 0 i) (first c)
>         (recur (rest c) (dec i))))
>
> Then I see some other people suggesting this as an answer:
>
> #((vec %) %2)
>
> Similarly question 32, which is to write a function which duplicates
> each element of a sequence, eg:
>
> (= (__ [1 2 3]) '(1 1 2 2 3 3))
>
> I came up with:
>
> #(loop [x % acc []]
>     (if (nil? (seq x))
>       (seq acc)
>       (recur (rest x) (conj (conj acc (first x)) (first x)))))
>
> and other people have suggested:
>
> #(reduce (conj coll %2 %2) [] coll)
>
> which is obviously much nicer than what I had.
>
> So my question is - how do we get to the point where we can get these
> really concise answers straight up?  Is it just something that comes
> with lots of "practice", or is it a sign that I've missed something
> fundamental when this kind of stuff just isn't jumping out at me
> immediately?  In particular - is the fact that I tend to go for loop /
> recur before anything else indicating I'm still thinking in a more
> "imperative" way?
>
> Thanks!
>
> Andrew.
>

Re: [foray] 4Clojure #21 and #32 (Spoiler)

From:
Sean Corfield
Date:
2013-05-27 @ 16:57
On May 27, 2013, at 6:46 AM, Andrew Myers wrote:
> So my question is - how do we get to the point where we can get these
> really concise answers straight up?  Is it just something that comes
> with lots of "practice", or is it a sign that I've missed something
> fundamental when this kind of stuff just isn't jumping out at me
> immediately?  In particular - is the fact that I tend to go for loop /
> recur before anything else indicating I'm still thinking in a more
> "imperative" way?

Partly it's practice - and reading other ppl's code will help - but partly
it's a mindshift that needs to happen at some point. loop/recur is very 
imperative and sometimes it's still the best way to solve a particular 
problem. It's also sometimes the way to get the fastest possible Clojure 
solution. But it's rarely the most idiomatic way to solve a problem.

Internalizing map and reduce can be tricky because you have to train 
yourself to think in terms of "whole data structures" but there's no easy 
trick to making that shift as far as I'm aware.

Yesterday on IRC, we were talking about how to return a sequence of all 
the subsequences of a given collection, i.e.,

	[1 2 3 4] ;;=> ((1) (1 2) (1 2 3) (1 2 3 4))

My first suggestion was:

	(defn list-seq3 [c]
	  (map take
	       (range 1 (inc (count c)))
	       (cycle (list c))))

Looking at the shape of the result, it was "obvious" that we could get it 
by successively calling (take 1 ..), (take 2 ..), (take 3 ..) so it seemed
like a mapping operation to me, with take being the function we needed to 
map and the arguments being [1 2 3 ..] and the original collection 
repeated each time.

I should have used (repeat c) instead of (cycle (list c)) tho' - but I 
think I got caught up on trying to create (1 2 3 4 1 2 3 4 ..) which of 
course is not quite what I needed anyway!

I noted that it wouldn't work with infinite sequences but offered up a 
similar version that would - using (iterate inc 1) instead of the range 
call - but that wouldn't work with finite sequences. After a bit of 
thought, I came up with this version that works for both finite and 
infinite sequences:

	(defn list-seq4 [c]
	  (map (fn [n l _] (take n l))
	       (iterate inc 1)
	       (repeat c)
	       c))

This uses the original collection itself to limit the number of items in 
the result, which will be correct for both finite and infinite sequences. 
Here map uses a function that takes 3 arguments but ignores the value of 
the 3rd argument - it's just for matching the size of the result to the 
size of the input. It's also probably clearer now to see that we are 
successively taking n elements from the collection each time.

Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



Re: [foray] 4Clojure #21 and #32 (Spoiler)

From:
Eric Pritchett
Date:
2013-05-28 @ 01:19
Hey Andrew,

I have worked through about half of the 4clojure problems, and I went
through the same experience as you. I believe that most of those answer are
either from people who have been writing Clojure for a while or from those
who were learning and went back to change their old answers. I learned a
lot about what other functions were available for a particular solution by
working through that site. Some of my favorites that I have discovered are
interleave, partition, partition-by, interpose, map-indexed, and juxt.
Every time you learn a new function, write yourself a note about what it
does and how to use it and you'll have them memorized in no time.


On Mon, May 27, 2013 at 11:57 AM, Sean Corfield <sean@corfield.org> wrote:

> On May 27, 2013, at 6:46 AM, Andrew Myers wrote:
> > So my question is - how do we get to the point where we can get these
> > really concise answers straight up?  Is it just something that comes
> > with lots of "practice", or is it a sign that I've missed something
> > fundamental when this kind of stuff just isn't jumping out at me
> > immediately?  In particular - is the fact that I tend to go for loop /
> > recur before anything else indicating I'm still thinking in a more
> > "imperative" way?
>
> Partly it's practice - and reading other ppl's code will help - but partly
> it's a mindshift that needs to happen at some point. loop/recur is very
> imperative and sometimes it's still the best way to solve a particular
> problem. It's also sometimes the way to get the fastest possible Clojure
> solution. But it's rarely the most idiomatic way to solve a problem.
>
> Internalizing map and reduce can be tricky because you have to train
> yourself to think in terms of "whole data structures" but there's no easy
> trick to making that shift as far as I'm aware.
>
> Yesterday on IRC, we were talking about how to return a sequence of all
> the subsequences of a given collection, i.e.,
>
>         [1 2 3 4] ;;=> ((1) (1 2) (1 2 3) (1 2 3 4))
>
> My first suggestion was:
>
>         (defn list-seq3 [c]
>           (map take
>                (range 1 (inc (count c)))
>                (cycle (list c))))
>
> Looking at the shape of the result, it was "obvious" that we could get it
> by successively calling (take 1 ..), (take 2 ..), (take 3 ..) so it seemed
> like a mapping operation to me, with take being the function we needed to
> map and the arguments being [1 2 3 ..] and the original collection repeated
> each time.
>
> I should have used (repeat c) instead of (cycle (list c)) tho' - but I
> think I got caught up on trying to create (1 2 3 4 1 2 3 4 ..) which of
> course is not quite what I needed anyway!
>
> I noted that it wouldn't work with infinite sequences but offered up a
> similar version that would - using (iterate inc 1) instead of the range
> call - but that wouldn't work with finite sequences. After a bit of
> thought, I came up with this version that works for both finite and
> infinite sequences:
>
>         (defn list-seq4 [c]
>           (map (fn [n l _] (take n l))
>                (iterate inc 1)
>                (repeat c)
>                c))
>
> This uses the original collection itself to limit the number of items in
> the result, which will be correct for both finite and infinite sequences.
> Here map uses a function that takes 3 arguments but ignores the value of
> the 3rd argument - it's just for matching the size of the result to the
> size of the input. It's also probably clearer now to see that we are
> successively taking n elements from the collection each time.
>
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
>
>

Re: [foray] 4Clojure #21 and #32 (Spoiler)

From:
Andrew Myers
Date:
2013-05-28 @ 03:21
Thanks Ali, Sean and Eric for your replies.  It sounds like
(hopefully) what I'm experiencing isn't unique to myself so there is
still hope for me to become a Functional (as opposed to dysfunctional)
Programmer. :)

Part to this is possibly just that I don't know enough of the
available functions yet.  I guess exposure to all these just comes
from reading (books and other people's code) and then trying to find
situations where they are the most appropriate thing to do.

I had "acidentally" skipped ahead to #32 in the list of 4Clojure
problems by the way (I must have had them sorted wrongly) so the next
one I am up to is 22 - http://www.4clojure.com/problem/22

I know I could do it with loop / recur- my first thought was that I
need some kind of "counter variable" but I think the fact I'm thinking
in terms of variables is concerning? :)

So now I'm trying to decide what else I could use.  Map doesn't seem
right for some reason because that still returns a sequence, right?
So I'm thinking maybe reduce might be involved here (although I may
only be thinking that because it's about the only other weapon I
currently have in my limited clojure "arsenal").

So my first attempt was:

(defn my-count [coll]
  (reduce #(+ 1 %) 0 coll))

This was a miserable failure because the function to reduce needs to
take 2 arguments.

So I did something really nasty, and came up with this, which works
when all the members of the collection are ints :-)

(defn my-count [coll]
  (reduce #(+ 1 % (* 0 %2)) 0 coll))

But that's completely stupid, because it won't work if the list
contains other types.

So now I'm stumped.  And I really don't want to "cheat" and look at
other people's answers before I solve it myself.  But I don't mind a
nudge in the right direction, if anyone wants to give me one.

Hopefully I'm not abusing the list by asking this kind of thing?  I
find talking through my thought processes helps give me a bit of
insight.  If it's better to take this stuff elsewhere, please let me
know.

Andrew.



On 28 May 2013 11:19, Eric Pritchett <eric.a.pritchett.che@gmail.com> wrote:
> Hey Andrew,
>
> I have worked through about half of the 4clojure problems, and I went
> through the same experience as you. I believe that most of those answer are
> either from people who have been writing Clojure for a while or from those
> who were learning and went back to change their old answers. I learned a lot
> about what other functions were available for a particular solution by
> working through that site. Some of my favorites that I have discovered are
> interleave, partition, partition-by, interpose, map-indexed, and juxt. Every
> time you learn a new function, write yourself a note about what it does and
> how to use it and you'll have them memorized in no time.
>
>
> On Mon, May 27, 2013 at 11:57 AM, Sean Corfield <sean@corfield.org> wrote:
>>
>> On May 27, 2013, at 6:46 AM, Andrew Myers wrote:
>> > So my question is - how do we get to the point where we can get these
>> > really concise answers straight up?  Is it just something that comes
>> > with lots of "practice", or is it a sign that I've missed something
>> > fundamental when this kind of stuff just isn't jumping out at me
>> > immediately?  In particular - is the fact that I tend to go for loop /
>> > recur before anything else indicating I'm still thinking in a more
>> > "imperative" way?
>>
>> Partly it's practice - and reading other ppl's code will help - but partly
>> it's a mindshift that needs to happen at some point. loop/recur is very
>> imperative and sometimes it's still the best way to solve a particular
>> problem. It's also sometimes the way to get the fastest possible Clojure
>> solution. But it's rarely the most idiomatic way to solve a problem.
>>
>> Internalizing map and reduce can be tricky because you have to train
>> yourself to think in terms of "whole data structures" but there's no easy
>> trick to making that shift as far as I'm aware.
>>
>> Yesterday on IRC, we were talking about how to return a sequence of all
>> the subsequences of a given collection, i.e.,
>>
>>         [1 2 3 4] ;;=> ((1) (1 2) (1 2 3) (1 2 3 4))
>>
>> My first suggestion was:
>>
>>         (defn list-seq3 [c]
>>           (map take
>>                (range 1 (inc (count c)))
>>                (cycle (list c))))
>>
>> Looking at the shape of the result, it was "obvious" that we could get it
>> by successively calling (take 1 ..), (take 2 ..), (take 3 ..) so it seemed
>> like a mapping operation to me, with take being the function we needed to
>> map and the arguments being [1 2 3 ..] and the original collection repeated
>> each time.
>>
>> I should have used (repeat c) instead of (cycle (list c)) tho' - but I
>> think I got caught up on trying to create (1 2 3 4 1 2 3 4 ..) which of
>> course is not quite what I needed anyway!
>>
>> I noted that it wouldn't work with infinite sequences but offered up a
>> similar version that would - using (iterate inc 1) instead of the range call
>> - but that wouldn't work with finite sequences. After a bit of thought, I
>> came up with this version that works for both finite and infinite sequences:
>>
>>         (defn list-seq4 [c]
>>           (map (fn [n l _] (take n l))
>>                (iterate inc 1)
>>                (repeat c)
>>                c))
>>
>> This uses the original collection itself to limit the number of items in
>> the result, which will be correct for both finite and infinite sequences.
>> Here map uses a function that takes 3 arguments but ignores the value of the
>> 3rd argument - it's just for matching the size of the result to the size of
>> the input. It's also probably clearer now to see that we are successively
>> taking n elements from the collection each time.
>>
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
>>
>>
>>
>

Re: [foray] 4Clojure #21 and #32 (Spoiler)

From:
Eric Pritchett
Date:
2013-05-28 @ 03:38
Here's a hint, you need map, reduce, and fn. There are several ways to
solve this problem, but the quickest one I could think of uses those main
clojure functions.


On Mon, May 27, 2013 at 10:21 PM, Andrew Myers <am2605@gmail.com> wrote:

> Thanks Ali, Sean and Eric for your replies.  It sounds like
> (hopefully) what I'm experiencing isn't unique to myself so there is
> still hope for me to become a Functional (as opposed to dysfunctional)
> Programmer. :)
>
> Part to this is possibly just that I don't know enough of the
> available functions yet.  I guess exposure to all these just comes
> from reading (books and other people's code) and then trying to find
> situations where they are the most appropriate thing to do.
>
> I had "acidentally" skipped ahead to #32 in the list of 4Clojure
> problems by the way (I must have had them sorted wrongly) so the next
> one I am up to is 22 - http://www.4clojure.com/problem/22
>
> I know I could do it with loop / recur- my first thought was that I
> need some kind of "counter variable" but I think the fact I'm thinking
> in terms of variables is concerning? :)
>
> So now I'm trying to decide what else I could use.  Map doesn't seem
> right for some reason because that still returns a sequence, right?
> So I'm thinking maybe reduce might be involved here (although I may
> only be thinking that because it's about the only other weapon I
> currently have in my limited clojure "arsenal").
>
> So my first attempt was:
>
> (defn my-count [coll]
>   (reduce #(+ 1 %) 0 coll))
>
> This was a miserable failure because the function to reduce needs to
> take 2 arguments.
>
> So I did something really nasty, and came up with this, which works
> when all the members of the collection are ints :-)
>
> (defn my-count [coll]
>   (reduce #(+ 1 % (* 0 %2)) 0 coll))
>
> But that's completely stupid, because it won't work if the list
> contains other types.
>
> So now I'm stumped.  And I really don't want to "cheat" and look at
> other people's answers before I solve it myself.  But I don't mind a
> nudge in the right direction, if anyone wants to give me one.
>
> Hopefully I'm not abusing the list by asking this kind of thing?  I
> find talking through my thought processes helps give me a bit of
> insight.  If it's better to take this stuff elsewhere, please let me
> know.
>
> Andrew.
>
>
>
> On 28 May 2013 11:19, Eric Pritchett <eric.a.pritchett.che@gmail.com>
> wrote:
> > Hey Andrew,
> >
> > I have worked through about half of the 4clojure problems, and I went
> > through the same experience as you. I believe that most of those answer
> are
> > either from people who have been writing Clojure for a while or from
> those
> > who were learning and went back to change their old answers. I learned a
> lot
> > about what other functions were available for a particular solution by
> > working through that site. Some of my favorites that I have discovered
> are
> > interleave, partition, partition-by, interpose, map-indexed, and juxt.
> Every
> > time you learn a new function, write yourself a note about what it does
> and
> > how to use it and you'll have them memorized in no time.
> >
> >
> > On Mon, May 27, 2013 at 11:57 AM, Sean Corfield <sean@corfield.org>
> wrote:
> >>
> >> On May 27, 2013, at 6:46 AM, Andrew Myers wrote:
> >> > So my question is - how do we get to the point where we can get these
> >> > really concise answers straight up?  Is it just something that comes
> >> > with lots of "practice", or is it a sign that I've missed something
> >> > fundamental when this kind of stuff just isn't jumping out at me
> >> > immediately?  In particular - is the fact that I tend to go for loop /
> >> > recur before anything else indicating I'm still thinking in a more
> >> > "imperative" way?
> >>
> >> Partly it's practice - and reading other ppl's code will help - but
> partly
> >> it's a mindshift that needs to happen at some point. loop/recur is very
> >> imperative and sometimes it's still the best way to solve a particular
> >> problem. It's also sometimes the way to get the fastest possible Clojure
> >> solution. But it's rarely the most idiomatic way to solve a problem.
> >>
> >> Internalizing map and reduce can be tricky because you have to train
> >> yourself to think in terms of "whole data structures" but there's no
> easy
> >> trick to making that shift as far as I'm aware.
> >>
> >> Yesterday on IRC, we were talking about how to return a sequence of all
> >> the subsequences of a given collection, i.e.,
> >>
> >>         [1 2 3 4] ;;=> ((1) (1 2) (1 2 3) (1 2 3 4))
> >>
> >> My first suggestion was:
> >>
> >>         (defn list-seq3 [c]
> >>           (map take
> >>                (range 1 (inc (count c)))
> >>                (cycle (list c))))
> >>
> >> Looking at the shape of the result, it was "obvious" that we could get
> it
> >> by successively calling (take 1 ..), (take 2 ..), (take 3 ..) so it
> seemed
> >> like a mapping operation to me, with take being the function we needed
> to
> >> map and the arguments being [1 2 3 ..] and the original collection
> repeated
> >> each time.
> >>
> >> I should have used (repeat c) instead of (cycle (list c)) tho' - but I
> >> think I got caught up on trying to create (1 2 3 4 1 2 3 4 ..) which of
> >> course is not quite what I needed anyway!
> >>
> >> I noted that it wouldn't work with infinite sequences but offered up a
> >> similar version that would - using (iterate inc 1) instead of the range
> call
> >> - but that wouldn't work with finite sequences. After a bit of thought,
> I
> >> came up with this version that works for both finite and infinite
> sequences:
> >>
> >>         (defn list-seq4 [c]
> >>           (map (fn [n l _] (take n l))
> >>                (iterate inc 1)
> >>                (repeat c)
> >>                c))
> >>
> >> This uses the original collection itself to limit the number of items in
> >> the result, which will be correct for both finite and infinite
> sequences.
> >> Here map uses a function that takes 3 arguments but ignores the value
> of the
> >> 3rd argument - it's just for matching the size of the result to the
> size of
> >> the input. It's also probably clearer now to see that we are
> successively
> >> taking n elements from the collection each time.
> >>
> >> Sean A Corfield -- (904) 302-SEAN
> >> An Architect's View -- http://corfield.org/
> >>
> >> "Perfection is the enemy of the good."
> >> -- Gustave Flaubert, French realist novelist (1821-1880)
> >>
> >>
> >>
> >>
> >
>

Re: [foray] 4Clojure #21 and #32 (Spoiler)

From:
Sean Corfield
Date:
2013-05-28 @ 03:40
On May 27, 2013, at 8:38 PM, Eric Pritchett wrote:
> Here's a hint, you need map, reduce, and fn.

You don't need map - although you certainly can solve it by mapping the 
the sequence to something else, then reducing it.

Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



Re: [foray] 4Clojure #21 and #32 (Spoiler)

From:
Sean Corfield
Date:
2013-05-28 @ 03:39
On May 27, 2013, at 8:21 PM, Andrew Myers wrote:
> I know I could do it with loop / recur- my first thought was that I
> need some kind of "counter variable" but I think the fact I'm thinking
> in terms of variables is concerning? :)

If you think you need some sort of accumulator, you're looking for reduce.

> (defn my-count [coll]
>  (reduce #(+ 1 %) 0 coll))

This is close, very close.

> This was a miserable failure because the function to reduce needs to
> take 2 arguments.

Indeed. The first argument is the (current) accumulator and the second 
argument is the element of the sequence... which you don't need... so you 
want:

	(fn [acc elem] ... what goes here? ...)

Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



Re: [foray] 4Clojure #21 and #32 (Spoiler)

From:
Andrew Myers
Date:
2013-05-28 @ 04:01
Woot!  Got it!  Thanks Sean (and Eric also).

I had overlooked that you could still use the (fn ...) way of defining
an anonymous function.

Appreciate your help!

Andrew.

On 28 May 2013 13:39, Sean Corfield <sean@corfield.org> wrote:
> On May 27, 2013, at 8:21 PM, Andrew Myers wrote:
>> I know I could do it with loop / recur- my first thought was that I
>> need some kind of "counter variable" but I think the fact I'm thinking
>> in terms of variables is concerning? :)
>
> If you think you need some sort of accumulator, you're looking for reduce.
>
>> (defn my-count [coll]
>>  (reduce #(+ 1 %) 0 coll))
>
> This is close, very close.
>
>> This was a miserable failure because the function to reduce needs to
>> take 2 arguments.
>
> Indeed. The first argument is the (current) accumulator and the second 
argument is the element of the sequence... which you don't need... so you 
want:
>
>         (fn [acc elem] ... what goes here? ...)
>
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
>

Re: [foray] 4Clojure #21 and #32 (Spoiler)

From:
Sean Chalmers
Date:
2013-05-28 @ 04:07
Congrats ! :D

Have you found any techniques for helping to think in functional style?
Currently it's my biggest stumbling block, I'm always hunting for an
iterator or index. For example the compress problem, I don't know if it's a
4Clojure problem too:

(compress '(a a a a b c c a a d e e e e))
(a b c a d e)

I keep wanting to check if-existing-in my current list, or
if-current-elem-is-same-as-last...  :(

I can start a new thread if people like, this just seems to build on the
original question... :)


On Tue, May 28, 2013 at 2:01 PM, Andrew Myers <am2605@gmail.com> wrote:

> Woot!  Got it!  Thanks Sean (and Eric also).
>
> I had overlooked that you could still use the (fn ...) way of defining
> an anonymous function.
>
> Appreciate your help!
>
> Andrew.
>
> On 28 May 2013 13:39, Sean Corfield <sean@corfield.org> wrote:
> > On May 27, 2013, at 8:21 PM, Andrew Myers wrote:
> >> I know I could do it with loop / recur- my first thought was that I
> >> need some kind of "counter variable" but I think the fact I'm thinking
> >> in terms of variables is concerning? :)
> >
> > If you think you need some sort of accumulator, you're looking for
> reduce.
> >
> >> (defn my-count [coll]
> >>  (reduce #(+ 1 %) 0 coll))
> >
> > This is close, very close.
> >
> >> This was a miserable failure because the function to reduce needs to
> >> take 2 arguments.
> >
> > Indeed. The first argument is the (current) accumulator and the second
> argument is the element of the sequence... which you don't need... so you
> want:
> >
> >         (fn [acc elem] ... what goes here? ...)
> >
> > Sean A Corfield -- (904) 302-SEAN
> > An Architect's View -- http://corfield.org/
> >
> > "Perfection is the enemy of the good."
> > -- Gustave Flaubert, French realist novelist (1821-1880)
> >
> >
> >
> >
>

Re: [foray] 4Clojure #21 and #32 (Spoiler)

From:
Eric Pritchett
Date:
2013-05-28 @ 04:10
Sean, you should look at
partition-by<http://clojuredocs.org/clojure_core/1.2.0/clojure.core/partition-by>,
but try not to read the examples if you don't like spoilers xD.


On Mon, May 27, 2013 at 11:07 PM, Sean Chalmers <sclhiannan@gmail.com>wrote:

> Congrats ! :D
>
> Have you found any techniques for helping to think in functional style?
> Currently it's my biggest stumbling block, I'm always hunting for an
> iterator or index. For example the compress problem, I don't know if it's a
> 4Clojure problem too:
>
> (compress '(a a a a b c c a a d e e e e))
> (a b c a d e)
>
> I keep wanting to check if-existing-in my current list, or
> if-current-elem-is-same-as-last...  :(
>
> I can start a new thread if people like, this just seems to build on the
> original question... :)
>
>
> On Tue, May 28, 2013 at 2:01 PM, Andrew Myers <am2605@gmail.com> wrote:
>
>> Woot!  Got it!  Thanks Sean (and Eric also).
>>
>> I had overlooked that you could still use the (fn ...) way of defining
>> an anonymous function.
>>
>> Appreciate your help!
>>
>> Andrew.
>>
>> On 28 May 2013 13:39, Sean Corfield <sean@corfield.org> wrote:
>> > On May 27, 2013, at 8:21 PM, Andrew Myers wrote:
>> >> I know I could do it with loop / recur- my first thought was that I
>> >> need some kind of "counter variable" but I think the fact I'm thinking
>> >> in terms of variables is concerning? :)
>> >
>> > If you think you need some sort of accumulator, you're looking for
>> reduce.
>> >
>> >> (defn my-count [coll]
>> >>  (reduce #(+ 1 %) 0 coll))
>> >
>> > This is close, very close.
>> >
>> >> This was a miserable failure because the function to reduce needs to
>> >> take 2 arguments.
>> >
>> > Indeed. The first argument is the (current) accumulator and the second
>> argument is the element of the sequence... which you don't need... so you
>> want:
>> >
>> >         (fn [acc elem] ... what goes here? ...)
>> >
>> > Sean A Corfield -- (904) 302-SEAN
>> > An Architect's View -- http://corfield.org/
>> >
>> > "Perfection is the enemy of the good."
>> > -- Gustave Flaubert, French realist novelist (1821-1880)
>> >
>> >
>> >
>> >
>>
>
>

Re: [foray] 4Clojure #21 and #32 (Spoiler)

From:
Sean Chalmers
Date:
2013-05-28 @ 04:14
Thanks Eric :)


On Tue, May 28, 2013 at 2:10 PM, Eric Pritchett <
eric.a.pritchett.che@gmail.com> wrote:

> Sean, you should look at 
partition-by<http://clojuredocs.org/clojure_core/1.2.0/clojure.core/partition-by>,
> but try not to read the examples if you don't like spoilers xD.
>
>
> On Mon, May 27, 2013 at 11:07 PM, Sean Chalmers <sclhiannan@gmail.com>wrote:
>
>> Congrats ! :D
>>
>> Have you found any techniques for helping to think in functional style?
>> Currently it's my biggest stumbling block, I'm always hunting for an
>> iterator or index. For example the compress problem, I don't know if it's a
>> 4Clojure problem too:
>>
>> (compress '(a a a a b c c a a d e e e e))
>> (a b c a d e)
>>
>> I keep wanting to check if-existing-in my current list, or
>> if-current-elem-is-same-as-last...  :(
>>
>> I can start a new thread if people like, this just seems to build on the
>> original question... :)
>>
>>
>> On Tue, May 28, 2013 at 2:01 PM, Andrew Myers <am2605@gmail.com> wrote:
>>
>>> Woot!  Got it!  Thanks Sean (and Eric also).
>>>
>>> I had overlooked that you could still use the (fn ...) way of defining
>>> an anonymous function.
>>>
>>> Appreciate your help!
>>>
>>> Andrew.
>>>
>>> On 28 May 2013 13:39, Sean Corfield <sean@corfield.org> wrote:
>>> > On May 27, 2013, at 8:21 PM, Andrew Myers wrote:
>>> >> I know I could do it with loop / recur- my first thought was that I
>>> >> need some kind of "counter variable" but I think the fact I'm thinking
>>> >> in terms of variables is concerning? :)
>>> >
>>> > If you think you need some sort of accumulator, you're looking for
>>> reduce.
>>> >
>>> >> (defn my-count [coll]
>>> >>  (reduce #(+ 1 %) 0 coll))
>>> >
>>> > This is close, very close.
>>> >
>>> >> This was a miserable failure because the function to reduce needs to
>>> >> take 2 arguments.
>>> >
>>> > Indeed. The first argument is the (current) accumulator and the second
>>> argument is the element of the sequence... which you don't need... so you
>>> want:
>>> >
>>> >         (fn [acc elem] ... what goes here? ...)
>>> >
>>> > Sean A Corfield -- (904) 302-SEAN
>>> > An Architect's View -- http://corfield.org/
>>> >
>>> > "Perfection is the enemy of the good."
>>> > -- Gustave Flaubert, French realist novelist (1821-1880)
>>> >
>>> >
>>> >
>>> >
>>>
>>
>>
>

Re: [foray] 4Clojure #21 and #32 (Spoiler)

From:
Eric Pritchett
Date:
2013-05-28 @ 04:05
Haha, glad you got it working.


On Mon, May 27, 2013 at 11:01 PM, Andrew Myers <am2605@gmail.com> wrote:

> Woot!  Got it!  Thanks Sean (and Eric also).
>
> I had overlooked that you could still use the (fn ...) way of defining
> an anonymous function.
>
> Appreciate your help!
>
> Andrew.
>
> On 28 May 2013 13:39, Sean Corfield <sean@corfield.org> wrote:
> > On May 27, 2013, at 8:21 PM, Andrew Myers wrote:
> >> I know I could do it with loop / recur- my first thought was that I
> >> need some kind of "counter variable" but I think the fact I'm thinking
> >> in terms of variables is concerning? :)
> >
> > If you think you need some sort of accumulator, you're looking for
> reduce.
> >
> >> (defn my-count [coll]
> >>  (reduce #(+ 1 %) 0 coll))
> >
> > This is close, very close.
> >
> >> This was a miserable failure because the function to reduce needs to
> >> take 2 arguments.
> >
> > Indeed. The first argument is the (current) accumulator and the second
> argument is the element of the sequence... which you don't need... so you
> want:
> >
> >         (fn [acc elem] ... what goes here? ...)
> >
> > Sean A Corfield -- (904) 302-SEAN
> > An Architect's View -- http://corfield.org/
> >
> > "Perfection is the enemy of the good."
> > -- Gustave Flaubert, French realist novelist (1821-1880)
> >
> >
> >
> >
>