Counting occurences
in [Lisp]
|
Prev: Black-Jewish History FAQ - Is The Secret Relationship between blacks and jews a “hate literature”?
Next: which library to generate xml with namespaces?
From: Tim Bradshaw on 19 Jun 2010 04:19 On 2010-06-18 22:01:46 +0100, Bob Felts said: > You're arguing about LOC, Ron is arguing about correct abstraction. Obviously I'm not arguing about LOC: I'm arguing about size (not in bytes, cognitive size perhaps?) and complexity, and using LOC as a poor proxy for that. > I > have to side with Ron on this one: getting the correct abstraction is > paramount above everything else. Small LOC is good if the abstraction > doesn't matter; it's easy to change programs with small LOC. No. maintainable, correct, adequately performant programs are all that matters. Abstraction may or may not help with that: we all know the horrors that result when people make the assumption that it always does. > Do you not expect Ron to understand it because you haven't explained it > well, or because you think Ron doesn't have the mental horsepower to > understand it? I think I haven't explained it well, and I'm not really going to try to do that here - if I had the energy to do so I'd be writing a book, not posting news articles. Gabriel's patterns book is the best description I know (and I note it's now available as a PDF), though it's a while since I read it and I'm sure I disagree with him about many things. However although it's not to do with "horsepower" (whatever that may mean - surely no one really believes in the single-number-describing-intelligence thing any more), it is to do with style of thinking. I don't really have the energy to get involved in a huge discussion about that, and for a long time I didn't really understand that there were such enormous differences in style: mostly because I didn't want to believe there were I think. What made me change my mind was realising that there were people who were genuinely good mathematicians (far better than me) but who just had no feel for physics at all, and similarly that there were people who were really quite good at physics who really could never get anywhere with number theory, say (I'm one of these). There are other enormous distinctions like this, and some of them are at work here. A couple of interesting ones are the system-vs-bits one (lots of computer people are on the right hand of that) and the closely-related meta one which is to do with whether you understand this whole argument (again, lots of computer people are on the bits side of that).
From: Tim Bradshaw on 19 Jun 2010 04:22 On 2010-06-19 01:47:54 +0100, RG said: > No. While it is true that the spec is not explicit about this, it does > place certain constraints on hash tables. For example, CL hash tables > cannot under any circumstances assume that the keys have a total order, > so they cannot be implemented by any underlying data structure that > requires that the keys be ordered. Of course they can. The implementation would just have to change dynamically if it noticed that there was no longer a total order it could use.
From: Tim Bradshaw on 19 Jun 2010 04:29 On 2010-06-18 22:04:44 +0100, RG said: > > This depends on how you count. LOC always depend on what you choose to > count as code and what you choose to count as library. You are using > LOOP, whose implementation is a helluva lot bigger than dictionaries. Indeed it does. This is to do with the whole application/library/language distinction which has been hashed out in cll before. As should be clear my view on that is that the middle ground is uninteresting: I want language-quality stuff (like LOOP) or nothing.
From: Rob Warnock on 19 Jun 2010 07:43 Bob Felts <wrf3(a)stablecross.com> wrote: +--------------- | Marcus Breiing <usenet(a)2010w24.mail.breiing.com> wrote: | > Piling complication on top of this simple abstraction could make sense | > in the context of advanced application design, but is it good | > paedagogy for beginners? | | Absolutely. In my opinion, one's first introduction to computers should | be about problem representation and abstraction of problem elements, | only then to be followed by programming languages. +--------------- See: http://htdp.org/ How to Design Programs An Introduction to Computing and Programming Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, & Shriram Krishnamurthi MIT Press (2003 edition) -Rob ----- Rob Warnock <rpw3(a)rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
From: Eric Wolf on 19 Jun 2010 07:52
"Frode V. Fjeld" <frode(a)netfonds.no> writes: > I'd use a plist because of the existence of (setf getf): > > (defun occurences-helper (list result) > (if (null list) > result > (progn > (incf (getf result (car list))) > (occurences-helper (cdr list) result)))) Ah, I had to read about plists in ACL before I did understand that. > But really I'd iterate normally: > > (defun occurences-helper (list) > (loop with result = nil > for element in list > do (incf (getf result element)) > finally (return result))) Grahams riots about loop a little bit. He says that the specification of loop in the ACL Standard would not be formal and so .. I must admit its easier to read though. > A different approach: > > (defun occurences (list) > (sort (mapcar (lambda (element) > (cons element > (count element list))) > (remove-duplicates list)) > #'> > :key #'cdr)) I really like that one. Since I first read about closures in lua, I asked myself, wether there really are situations where they help. And here is one now! Thanks. Yours, Eric |