Like here: https://clojuredocs.org/clojure.core

I think this is community maintained, no?

Ah okay, I’m answering my own question: https://github.com/zk/clojuredocs/pull/246

The comments are community maintained but the site is still run by a single person who has sadly been absent

The official Clojure API docs are at http://clojure.github.io/clojure/

Seems like you're trying to realize a sequence that is too large. You can also reproduce it like this: (count (combo/partitions [1 1 2 3 4 5] :min 5 :max 5))

or maybe not?

How do you mean a sequence that is too large?

no its not too large

it's something else, i jumped to conclusions

it only seems to happen when there are duplicate 1's for me so far

other numbers seem fine?

it's not about being 1's. this also fails:

(dorun (combo/partitions [2 3 4 5 1 2] :min 5 :max 5))

where the first item is duplicated

ah. good find!

this doesnt:

(dorun (combo/partitions [3 2 4 5 1 2] :min 5 :max 5))

i tried to read the source code... but its way above my paygrade so I can't help you there 😄

I think a function with an args list like this:

[n m f c u v a b l r s]

As this has been replicated, and I think I understand the conditions for throwing an error a little better, I've made a post on ask clojure: https://ask.clojure.org/index.php/12673/clojure-combinatorics-partitions-throw-error-duplicate-items

Cc @U0516PHE3 , the author

@UE1N3HAJH you definitely found a bug! it’s broken right at the start, before the error, when it generates

([1 4] [1] [2 3] [2 3] [2 3])

since that’s no longer a partition

woah, I think I’ve got it

https://clojure.atlassian.net/browse/MCOMB-11

@UE1N3HAJH phew, okay, I’d love to know if this fixes the issues that you’ve seen with other groups of numbers!

Thanks @U017QJZ9M7W - great work! All looks good to me, as commented on the ticket. I hope it gets merged soon 🎉

Maybe worth pinging @U0518RMLD instead as I think he's actually the author.

https://clojurians.slack.com/archives/C06MAR553/p1679156410467269

Proper fix released, my old patch wasn’t great, it generated all small partitions then filtered them so performance was poor

Great job! Thanks for working on this!

If it's performance that you're worrying about, it should be possible to write your own "caching nth" that uses a transient vector as an indexed cache. If you want readability, nth along with every? are probably the best bet here. Although, every? helps in the above case as well.

Oh, but since the predicate collection is sorted by index, I'd probably go with loop.

My worry was that without vectors Indexed, nth would start from 0 every time. So as the indexes get bigger, the O(n) traversal would grow too. Would it be worth using nthnext or something and calculating the distance from index to index?

nth would indeed start from the very start every time. nthnext is no different - it just returns the tail and not the item at that position. You can use multiple calls to drop in e.g. a reduce but you'd have to keep track of the current index.

Something like this, although there are probably more clever solutions:

(def index+pred [[1 int?]
                 [5 pos?]
                 [18 #(> % 3)]
                 [200 zero?]])

(def coll (range))

(def result (boolean (reduce (fn [[coll curr-idx] [idx pred]]
                               (let [n (- idx curr-idx)
                                     coll (drop n coll)
                                     item (first coll)]
                                 (if (pred item)
                                   [coll idx]
                                   (reduced false))))
                             [coll 0]
                             index+pred)))

That’s great, thank you. I’ll give that a whirl

What would be really neat is the ability to project a sequence over a sequence of indices (sort of like in MATLAB)

Ah yeah, indeed. Something like this:

(defn project [indices coll]
  (letfn [(step [curr-idx indices coll]
            (lazy-seq
              (when-let [indices (seq indices)]
                (when-let [coll (seq coll)]
                  (let [idx (first indices)
                        n (- idx curr-idx)
                        coll (drop n coll)
                        item (first coll)]
                    (cons item (step idx (next indices) coll)))))))]
    (step 0 indices coll)))

Yes, although this assumes the input is sorted and unique, but it's a good fit for sequences

Sorted - yes. Unique - no. drop accepts 0 as n.

Oh, that's kind of it 😄

I wrote some code recently which takes an offset rather than a roll-length, so it supplies each item, along with the items n in front of, or behind it, depending on if offset is positive or negative:

(defn partition-offset
  ([offset coll]
   (if (neg? offset)
     (let [abs-offset (abs offset)]
       (concat (map #(take % coll) (range 1 abs-offset))
               (partition abs-offset 1 coll)))
     (partition-all offset 1 coll))))

For clarity, your code would then look like this:

(->> coll
     (partition-offset -3)
     (map #(/ (reduce + %) (count %))))

Just in case - averages in particular could be made much more performant if you don't use something generic for it because (count %) is always the same and (reduce + %) can be replaced with a single - followed by a +.

For this function, the count isn't always the same, because partitions "off the edge" of the collection are shorter, rather than being padded with nils or 0s. Probably a good argument for allowing padding :thinking_face:

Ah, right. But that can also be taken into consideration, whether with or without a padding - depending on how you roll [the windows]. :)

partition allows for creating windows like this

(let [average (fn [nums]
                  (/ (apply + nums) (count nums)))]
    (->> (range 30)
         (partition 3 1)
         (map average)))

(defn window [n]
  (fn [rf]
    (let [win (volatile! [])]
      (fn
        ([] (rf))
        ([r]
         (rf (reduce rf r (take-while not-empty (iterate (partial into [] (drop 1)) @win)))))
        ([r x]
         (rf r (vswap! win (fn [w]
                             (let [w' (conj w x)]
                               (if (-> w' count (> n))
                                 (subvec w' 1)
                                 w'))))))))))

(comment

  (let [average (fn [nums]
                  (/ (apply + nums) (count nums)))]
    (sequence (comp (window 3) (map average)) (range 10))) ;; => (0 1/2 1 2 3 4 5 6 7 8 8 17/2 9)

  )

The most efficient thing here would be an exponential moving average

What does weighing have to do with efficiency?

That particular algorithm processes 1 item at a time and doesn’t need to access windows of the data

another nice one is an “exponential histogram”, which can give you an approximate rolling-window average with a guaranteed error bound with much lower memory than keeping the full window in memory

(here’s a safer average implementation than the one above, btw https://github.com/sicmutils/sicmutils/pull/454/files#diff-d25b73310b8c6a6ba432519e6a68ee73fc9a77909c007679b9f2d57b3e5af949R35-R66)

exponential histogram code in Scala, from back in the day: https://github.com/twitter/algebird/blob/develop/algebird-core/src/main/scala/com/twitter/algebird/ExpHist.scala#L7 “decayed value”: https://github.com/twitter/algebird/blob/develop/algebird-core/src/main/scala/com/twitter/algebird/DecayedValue.scala#L17 definitely nice to skip the window, and you can use reductions to track the averaged value as you add in items, of course

Sorry, I probably missed the point of the actual question. I thought he was more asking about how to do rolling window type things than actually calculating an average.

That’s probably true, I was just dropping additional breadcrumbs

@U0P0TMEFJ, actually, yes, you are absolutely right, I am about the rolling window type. I am using the code you recomended.

(let [average (fn [nums]
                  (/ (apply + nums) (count nums)))]
    (->> (range 30)
         (partition 3 1)
         (map average)))

Cool ... Glad that's working for you ;)

In this case @U012GN57FJ9 (count nums) is always 3!