Question

Here is a problem Statement :

Define a procedure that takes three numbers as arguments and returns the sum of the squares of the two larger numbers.

The solution is long,

(defn large [x y]
(if (> x y) x y))

(defn large-3 [x y z]
(if(> (large x y) z) (large x y) z))

(defn small [x y]
(if (< x y) x y))

(defn small-3 [x y z]
(if (< (small x y) z ) (small x y) z))

(defn second-largest [x y z]
  (let [greatest (large-3 x y z)
    smallest (small-3 x y z)]
    (first (filter #(and (> greatest %) (< smallest %)) [x y z]))))

(defn square [a]
  (* a a)
)

(defn sum-of-square [x y z]
  (+ (square (large-3 x y z)) (square (second-largest x y z))))

Just wanted to know what different/succinct ways this problem can be solved in Clojure.

Answer 1

(See a sequence version of the problem together with a lazy solution in my second update to this answer below.)

(defn square [n]
  (* n n))

;; generalises easily to larger numbers of arguments
(defn sum-of-larger-squares [x y z]
  (apply + (map square (take 2 (reverse (sort [x y z]))))))

;; shorter; generalises easily if you want
;; 'the sum of the squares of all numbers but n smallest'
(defn sum-of-larger-squares [x y z]
  (apply + (map square (drop 1 (sort [x y z])))))

Update:

To expand on the comments from the above, the first version’s straighforward generalisation is to this:

(defn sum-of-larger-squares [n & xs]
  (apply + (map square (take n (reverse (sort xs))))))

The second version straightforwardly generalises to the version Arthur posted in the meantime:

(defn sum-of-larger-squares [n & xs]
  (apply + (map square (drop n (sort xs)))))

Also, I’ve seen exactly the same problem being solved in Scheme, possibly even on SO… It included some fun solutions, like one which calculated the some of all three squares, then subtracted the smallest square (that’s very straightforward to express with Scheme primitives). That’s ‘unefficient’ in that it calculates the one extra square, but it’s certainly very readable. Can’t seem to find the link now, unfortunately.

Update 2:

In response to Arthur Ulfeldt’s comment on the question, a lazy solution to a (hopefully fun) different version of the problem. Code first, explanation below:

(use 'clojure.contrib.seq-utils) ; recently renamed to clojure.contrib.seq

(defn moving-sum-of-smaller-squares [pred n nums]
  (map first
       (reductions (fn [[current-sum [x :as current-xs]] y]
                     (if (pred y x)
                       (let [z (peek current-xs)]
                         [(+ current-sum (- (* z z)) (* y y))
                          (vec (sort-by identity pred (conj (pop current-xs) y)))])
                       [current-sum
                        current-xs]))
                   (let [initial-xs (vec (sort-by identity pred (take n nums)))
                         initial-sum (reduce + (map #(* % %) initial-xs))]
                     [initial-sum initial-xs])
                   (drop n nums))))

The clojure.contrib.seq-utils (or c.c.seq) lib is there for the reductions function. iterate could be used instead, but not without some added complexity (unless one would be willing to calculate the length of the seq of numbers to be processed at the start, which would be at odds with the goal of remaining as lazy as possible).

Explanation with example of use:

user> (moving-sum-of-smaller-squares < 2 [9 3 2 1 0 5 3])
(90 13 5 1 1 1)

;; and to prove laziness...
user> (take 2 (moving-sum-of-smaller-squares < 2 (iterate inc 0)))
(1 1)

;; also, 'smaller' means pred-smaller here -- with
;; a different ordering, a different result is obtained
user> (take 10 (moving-sum-of-smaller-squares > 2 (iterate inc 0)))
(1 5 13 25 41 61 85 113 145 181)

Generally, (moving-sum-of-smaller-squares pred n & nums) generates a lazy seq of sums of squares of the n pred-smallest numbers in increasingly long initial fragments of the original seq of numbers, where ‘pred-smallest’ means smallest with regard to the ordering induced by the predicate pred. With pred = >, the sum of n greatest squares is calculated.

This function uses the trick I mentioned above when describing the Scheme solution which summed three squares, then subtracted the smallest one, and so is able to adjust the running sum by the correct amount without recalculating it at each step.

On the other hand, it does perform a lot of sorting; I find it’s not really worthwhile to try and optimise this part, as the seqs being sorted are always n elements long and there’s a maximum of one sorting operation at each step (none if the sum doesn’t require adjustment).