I have this assignment:
Consider a list where every element is a nested list of length 2. The first
element of each nested list is either a 0 or a 1. The second element of each nested list
is some integer. An example input in Scheme is written below.
'((0 1) (1 2) (1 3) (0 4) (0 3))
For the purposes of this question, let’s call the first element of each nested list the
key and the second element of the nested lists the value. Now consider a function,
count_by_cat, that takes such a list as input and yields a two-element list where
the first element is the sum of the values of all nested lists with 0 as the key,
and
the second element is the sum of the values of all nested lists with 1 as the key
Implement count_by_cat in
(a) Racket, and
(b) ML.
It might be helpful to create helper functions. Also do not forget about map and filter
(filter is not a built-in in ML).
I'm new to Racket and ML. I'm stuck at using accessing lists and stuff in Racket. Some help with ML would also be great.
Well you're suggested to use higher order functions like map and filter.
And indeed it is easy to manipulate our data as a whole instead of focusing, mentally, on one element at a time. Which approach (i.e. the former one) some might argue, is the essence of functional programming paradigm.
In Racket,
(define (count_by_cat ls)
"return a two-element list"
(list
;; .....
;; ..... ))
where the first element is the sum of
(sum-of
the values of all nested lists
(map value
with 0 as the key
(filter (lambda (x) (= 0 (key x))) ls)))
and the second element is the sum of the values of all nested lists
(sum-of
(map value
with 1 as the key
(filter (lambda (x) (= 1 (key x))) ls))) ))
And so we need to define the helper functions accessing the nested lists,
(define (key n) (car n))
(define (value n) (cadr n))
and also the sum-of function, for summing up the numerical values in a list:
(require math/base)
(define (sum-of ls)
(sum ls))
This was easy to write, and will be easy to maintain.
The more performant code would do everything in one pass over the input, like is shown in the other answer. It has all the logic fused into one loop body. It could be more brittle to write and maintain.
The hint about map and filter is a bit of a red herring (As well as being wrong about them not being in ML languages); a helper function is very useful, but it's a fold you want, which basically calls a function with the current element of a list and an accumulator value, and uses what it returns as the accumulator for the next element and ultimately the return value of the entire fold.
For example, in ocaml, using a fold to sum a list of integers:
let sum = List.fold_left (+) 0 [ 1; 2; 3; 4; 5 ];;
((+) is the function version of the infix operator +).
Or your problem in Racket, using the for/fold comprehension, and returning two values instead of a two-element list, which is more idiomatic in Racket and Scheme (In ocaml and presumably Standard ML, you'd return a two-element tuple instead of a list, and take a list of tuples).
(define (count-by-cat lol)
(for/fold ([zero-sum 0]
[one-sum 0])
([elem (in-list lol)])
(case (first elem)
[(0) (values (+ zero-sum (second elem)) one-sum)]
[(1) (values zero-sum (+ one-sum (second elem)))])))
You could also use foldl, but for/fold is often easier to use, especially when working with multiple values or other non-trivial cases.
Related
I have the following Common Lisp Function:
(defun test(A &rest indexes)
(if (null (first indexes))
A
(test (nth (+ 1 (first indexes)) A) (rest indexes))
)
)
As far as I know &rest parameters are treated as a list in the function body but since
(rest indexes) also returns a list I'm stuck with nested Lists as parameters.
For example (test '("a" "b" "c" ("d" "e")) 3 1 6 7)
would cause indexes to be ((1 6 7)) at the second call.
Is there any way to pass my list without having this problem?
Basic style rule: don't use &rest arguments for list processing functions.
Why? Common Lisp implementations are allowed to only support up to the value of CALL-ARGUMENTS-LIMIT number of arguments. This number is 50 or larger, depending on implementation.
This means your function might in some implementation process lists not larger as fifty items.
Better: pass the list as a separate argument.
(defun test (A indexes)
...)
(test '("a" "b" "c" ("d" "e")) '(3 1 6 7))
Wrong solution: don't use apply, since it does not solve the problem of limited argument lists.
CLISP
[1]> call-arguments-limit
4096
[2]> (defun l1 (&rest l) l)
L1
[3]> (apply #'l1 (loop repeat 5000 collect 1))
*** - APPLY: too many arguments given to
#<FUNCTION L1 (&REST L)
(DECLARE (SYSTEM::IN-DEFUN L1))
(BLOCK L1 L)>
The following restarts are available:
ABORT :R1 Abort main loop
rest is a accessor function that is paired together with first to give you the first element and the rest of the list. rest is the same as cdr.
&rest is a lambda list keyword that slurps the remaining arguments in the variable name that follows it.
You are really looking for apply. Imagine I make a function that can take 0 or more numeric parameters and add them together:
(defun add (&rest numbers)
(apply #'+ numbers))
Apply can take more than two arguments. The first is the function to call and all but the last are extra arguments that are put in front of the last arguments element. You are guaranteed the implementation supports 50 arguments or upto the number of arguments a function can take in that particular implementation supports above 50.
(apply #'+ 1 2 '(3 4 5)) ; ==> 15
Now recursing by &rest and apply makes inefficient code so you should use higher order functions, loop macro, or make a helper:
;; higher order function
(defun fetch-indexes (a &rest indexes)
(mapcar (lambda (i) (nth i a)) indexes))
;; loop macro
(defun fetch-indexes (a &rest indexes)
(loop :for i :in indexes
:collect (nth i a)))
;; helper function
(defun fetch-indexes (a &rest indexes)
(labels ((helper (indexes)
(if (endp indexes)
'()
(cons (nth (first indexes) a)
(helper (rest indexes))))))
(helper indexes)))
;; test (works the same with all)
(fetch-indexes '(a b c d) 2 3 0 1)
; ==> (c d a b)
Using apply in recursion should be avoided, but I'll show how it's done.
(defun fetch-indexes (a &rest indexes)
(if (endp indexes)
'()
(cons (nth (first indexes) a)
(apply #'fetch-indexes a (rest indexes)))))
In your example you have nested lists. In order for that to work you would need to flatten it as well. I haven't done that so these supports one proper list of elements.
Another solution, albeit a bit more verbose, but less reliant on details of apply is to use a sub-function for the recursion, which just takes a list. The outer "main" entry point takes the &rest indices syntax, while the inner function takes it as a list:
(defun test (a &rest indices)
(labels ((internal-test (indices)
;; ... the recursion thing calling internal-test
))
(internal-test indices)))
In contrast to the (defun add (&rest args) ... ) example, you might still have some arguments before the rest, which in case of using apply would require you to append those to the variable arguments list.
Of course, as Rainer Joswig pointed out, you need to take care only to use this, when the number of variable args is small.
Is there a function in the Clojure standard library equivalent to the following?
(fn [& args] args)
If not, why?
Example usage:
(take 10 (apply (fn [& args] args) (range)))
;=> (0 1 2 3 4 5 6 7 8 9)
;; ironically, map isn't lazy enough, so let's take it up to 11
(defn lazy-map [f & colls]
(lazy-seq (cons (apply f (map first colls))
(apply lazy-map f (map rest colls)))))
(defn transpose [m]
(apply lazy-map (fn [& args] args) m))
(defn take-2d [rows cols coll]
(take rows (map (partial take cols) coll)))
(take-2d 3 3 (transpose (map (partial iterate inc) (range))))
;=> ((0 1 2) (1 2 3) (2 3 4))
Please note that I am not asking for a transformative, eager function such as vector or list.
There is no such function, you are free to implement and use it as you like:
(defn args [& args] args)
(set (map type (apply map args [[1 2 3][4 5 6][7 8 9]])))
=> #{clojure.lang.ArraySeq}
Why isn't it already available?
This is rarely fruitful question: not only we don't know what happens in the mind of implementors, it is impracticable to ask them to justify or document why they did not do something. Was adding this function ever considered? How can we know? Is there really a reason, or did it just happen?
On the other hand, I agree that args feels simpler because it passes around an already existing immutable sequence.
I also can understand if you think that not converting the arguments as a persistent list in the first place is better, if only for the sake of parcimony.
But this is not how it is implemented, and the overhead of using list is really negligible (and specialized when building from an instance of ArraySeq).
You are supposed to code to an interface and never look behind the curtain, and from this point of view, list and args are equivalent, even though they do not return identical results.
You added a remark about laziness, and you are right: if you ever need to take the arguments from a variadic function and pass it to a function which operates on sequences, The version with list will consume all the given arguments whereas args will not. In some cases, as with (apply list (range)), where you literally pass an infinite number of arguments, this might hang forever.
From that point of view, the little args function is in fact interesting: you can move from arguments to actual sequences without introducing potential problems.
I am however not sure how often this case happens in practice.
In fact, I have a hard time finding a use case where laziness in the argument list really matters as far as args is concerned.
After all, in order to pass an infinite sequence, the only way (?) is to use apply:
(apply f (infinite))
In order to have a use-case for args, that means that we want to convert from an argument list back to a single list so that another function g can use it as a sequence, like so:
(g (apply args (infinite)))
But in that case, we could directly call:
(g (infinite))
In your example, g would stand for cons inside lazy-map, but since f is given in input, we cannot write (cons (map ...) ...) directly. The example thus looks like a genuine use case for args, but you should document the function heavily because the snippet you gave is quite complex. I tend to think that giving an unbounded number of arguments to a function is a code smell: should every function with an [& args] signature avoid consuming all arguments because the given sequence might in fact be infinite, like lazy-map does? I'd rather have a single argument be a lazy sequence for this kind of usage (and pass identity where needed) instead of the whole argument list, to clarify the intent. But in the end, I am not strongly opposed to the use of args either.
So to conclude, unless you manage to convince Rich Hickey to add args as a core function, I am confident that almost nobody will want to depend on an external library which does just this1: it is unfamiliar, but also trivial to implement and mostly useless. The only reward is knowing that you skip a little transformation step which costs nothing in most cases. Likewise, do not worry about having to choose between a vector and a list: it has practically no influence on your code and you can still modify the code later if you can prove it is necessary.
Regarding laziness, while I agree that wrapping arguments in lists or vectors can be problematic with unbounded argument lists, I am not sure the problem actually arises in practice.
1. Of course, if it ever reaches clojure.core, everybody will be quick to say that is is a fundamental operation which is most useful and definitely idiomatic </cynic>
There's identity function. It takes an argument and just returns that argument. Clojure's identity is single arity though.
usage:
(identity 4) ;=> 4
(identity [1 2 3 4]) ;=> [1 2 3 4]
I don't think there's much sense in having the identity function with variable arity since Clojure functions return only one value. If you want to return multiple values from a function, then you can wrap them in a seq which you can later destructure. In that case you can have something like this:
(defn varity-identity [& args]
(map identity args))
(varity-identity 1 2 3 4 5) ;=> (1 2 3 4 5)
Hope this helps.
I'm passing the name of a function for use in another method.
(defn mapper [m function]
(cond
(= '() m) '()
true (cons (function (first m))
(mapper (rest m) function))))
(println (mapper '((blue red)(green red)(white red)) #'first))
Is there a more idiomatic way to do this in clojure?
Prefer vectors to lists. You don't have to quote a vector most of the time, and it has better performance for a lot of things, like random access. Lists are used much more rarely in Clojure than in other Lisps.
Prefer keywords to quoted symbols. Keywords stand out as "constant strings" or enumerated values. Keywords in Clojure can belong to a namespace, so they have all the advantages of symbols. And again, there's no need to quote keywords, which is nice. Quoted symbols are used pretty rarely in Clojure, unless you're writing macros.
#'first is the var called "first"; first is the value of the var called "first", i.e. the fn. In this case (#'first foo) and (first foo) give the same answer, but #'first does an extra dereference every time you call it. So don't do this unless you want that dereference to happen over and over. There's usually no need to use #'.
The built-in map is lazy, whereas yours isn't. The built-in map takes advantage of chunked seqs for better performance, whereas yours doesn't. Idiomatic code doesn't have to be lazy or use chunked seqs, but keep in mind that the builtins have some of this magic going on. So it's good to take advantage.
Rather than (= '() x), the idiomatic test for an empty seq is (seq x), which returns nil if x is empty. Note that in Clojure, (= '() nil) is false.
If you do ever need to use the empty list (which you should rarely need to do), you don't have to quote it. Just use ().
Built-in map takes the function argument first because it accepts multiple collection arguments. When a function takes multiple arguments, those arguments have to go last in the argument list. I think it reads better the other way too: "(map f coll): map this function across this collection".
There's no need to use cond if you only have two options. You can use if instead. And if one of the branches in your if returns nil, you can use when. It's nice to use when and if when appropriate, because they signal your intentions to the reader immediately, whereas cond could do anything and forces the reader to read more.
Rafał Dowgird's version is idiomatic, except I'd flip the order of arguments around. And I'd call it like this:
user> (mapper first [[:blue :red] [:green :red] [:white :red]])
(:blue :green :white)
I believe you got it mostly idiomatic. Clojure's own map uses:
(defn mapper [coll f]
(when-let [s (seq coll)]
(cons (f (first s)) (mapper (rest s) f))))
I have shortened it severely - the original produces a lazy sequence, deals with multiple collections, chunked-seqs, etc. By the way - I assume you want to pass the actual function, not it's name.
The coll and f are idiomatic arg names to represent collections and functions, respectively.
Your version looks good to me. The usual names you will see in the clojure code base is 'coll' for collections. I have also seen 'xs' which is the Haskell style, I think. You may also refer to the Clojure library coding standards on various conventions.
Coming back to the example: Two observations.
Use :else for 'cond' as the escape condition, instead of the Common Lisp style 'T'.
Instead of assuming lists, think sequences.
With these two in mind, if I rewrite your code:
user> (defn mapper [coll f]
(cond
(not (seq coll)) nil
:else (conj (mapper (next coll) f)
(f (first coll)))))
#'user/mapper
user> (mapper '(1 2 3) #(* % %))
(1 4 9)
user> (mapper [1 2 3] #(* % %))
(1 4 9)
Note that conj does the "right thing" as far as collections are concerned. It adds the new element to the head of a list, to the tail of a vector and so on. Also note the use of 'next' instead of the first/rest idioms in traditional lisp. 'next' returns a sequence of elements after the first element. So, empty-ness can be checked by seq'ing on the collection which will return nil for an empty list or an empty vector. This way it works for all collections.
I'm trying to use scheme to write a function f that takes a number n and a function g and returns a list of lists of length n, but according with booleans according to the pattern indicated by g. For example, the function f should take n say 3 and the function g which makes every 3rd item on the list a true. It should return this:
(list (list true true false)
(list true true false)
(list true true false))
I have no idea where to start with this, so any help or tips would be greatly appreciated. THanks!
Key to this looks like using map.
In short, map takes a function and a list, and applies the function to that list, returning the modified list.
To do this, as I'm assuming you don't want a direct solution, I'd first construct your list of lists (just use an accumulator -- count down -- to make the list as long as needed, and use cons and list and quote for everything else.
Then simply apply map (probably twice, depending on how you implement your solution) to the list of lists. (eg list l and function fn: (map fn (car l)) and recur with the cdr of l and cons the results back together).
Good luck! Hope this helps!
I don't quite follow what you're trying to do, but in addition to map, you might find build-list to be useful. build-list takes a number and a procedure, takes the range from 0 to that number less 1, and maps your procedure over that range. e.g.
> (build-list 5 (lambda (x) (* x x)))
(0 1 4 9 16)
I'm trying to pass a list to a function in Lisp, and change the contents of that list within the function without affecting the original list. I've read that Lisp is pass-by-value, and it's true, but there is something else going on that I don't quite understand. For example, this code works as expected:
(defun test ()
(setf original '(a b c))
(modify original)
(print original))
(defun modify (n)
(setf n '(x y z))
n)
If you call (test), it prints (a b c) even though (modify) returns (x y z).
However, it doesn't work that way if you try to change just part of the list. I assume this has something to do with lists that have the same content being the same in memory everywhere or something like that? Here is an example:
(defun test ()
(setf original '(a b c))
(modify original)
(print original))
(defun modify (n)
(setf (first n) 'x)
n)
Then (test) prints (x b c). So how do I change some elements of a list parameter in a function, as if that list was local to that function?
Lisp lists are based on cons cells. Variables are like pointers to cons cells (or other Lisp objects). Changing a variable will not change other variables. Changing cons cells will be visible in all places where there are references to those cons cells.
A good book is Touretzky, Common Lisp: A Gentle Introduction to Symbolic Computation.
There is also software that draws trees of lists and cons cells.
If you pass a list to a function like this:
(modify (list 1 2 3))
Then you have three different ways to use the list:
destructive modification of cons cells
(defun modify (list)
(setf (first list) 'foo)) ; This sets the CAR of the first cons cell to 'foo .
structure sharing
(defun modify (list)
(cons 'bar (rest list)))
Above returns a list that shares structure with the passed in list: the rest elements are the same in both lists.
copying
(defun modify (list)
(cons 'baz (copy-list (rest list))))
Above function BAZ is similar to BAR, but no list cells are shared, since the list is copied.
Needless to say that destructive modification often should be avoided, unless there is a real reason to do it (like saving memory when it is worth it).
Notes:
never destructively modify literal constant lists
Dont' do: (let ((l '(a b c))) (setf (first l) 'bar))
Reason: the list may be write protected, or may be shared with other lists (arranged by the compiler), etc.
Also:
Introduce variables
like this
(let ((original (list 'a 'b 'c)))
(setf (first original) 'bar))
or like this
(defun foo (original-list)
(setf (first original-list) 'bar))
never SETF an undefined variable.
SETF modifies a place. n can be a place. The first element of the list n points to can also be a place.
In both cases, the list held by original is passed to modify as its parameter n. This means that both original in the function test and n in the function modify now hold the same list, which means that both original and n now point to its first element.
After SETF modifies n in the first case, it no longer points to that list but to a new list. The list pointed to by original is unaffected. The new list is then returned by modify, but since this value is not assigned to anything, it fades out of existence and will soon be garbage collected.
In the second case, SETF modifies not n, but the first element of the list n points to. This is the same list original points to, so, afterwards, you can see the modified list also through this variable.
In order to copy a list, use COPY-LIST.
it's nearly the same as this example in C:
void modify1(char *p) {
p = "hi";
}
void modify2(char *p) {
p[0] = 'h';
}
in both cases a pointer is passed, if you change the pointer, you're changing the parameter copy of the pointer value (that it's on the stack), if you change the contents, you're changing the value of whatever object was pointed.
You probably have problems because even though Lisp is pass-by-value references to objects are passed, like in Java or Python. Your cons cells contain references which you modify, so you modify both original and local one.
IMO, you should try to write functions in a more functional style to avoid such problems. Even though Common Lisp is multi-paradigm a functional style is a more appropriate way.
(defun modify (n)
(cons 'x (cdr n))