Clojurians Log v2

Is it a bug?

(partition 3 1 [:a :b :c] (range 5))
; => ((0 1 2) (1 2 3) (2 3 4) (3 4 :a))

Isn’t it working exactly as described in docstring?

The docstring is ambiguous on this point.

as a comparison with partition-all, there is an inconsistency.

(partition-all 3 1 (range 5))
=> ((0 1 2) (1 2 3) (2 3 4) (3 4) (4))

if partition was behaving consistently with partition-all, it should be:

(partition 3 1 [:a :b :c] (range 5))
; => ((0 1 2) (1 2 3) (2 3 4) (3 4 :a) (4 :a :b))

hm… but docstring for partition is not mentioning partition-all however I can see some problems with that sentence:

If a pad collection is supplied, use its elements as
necessary to complete last partition upto n items.

there should be an emphasis on the "last partition" with no s

But yeah ... the last partition is not defined.

of it could be first incomplete partition

(partition 3 3 [:a :b :c] (range 9))
=> ((0 1 2) (3 4 5) (6 7 8))

I think that it is a bug.

what do you expect?

I would expect the "last partition" to be: > > The last partition to contain elements from the input collection (not the padding collection) which are not present in any previous partition.

but this (6 7 8) is that partition, isn’t it?

It would mean:

(partition 3 3 [:a :b :c] (range 10))
; => ((0 1 2) (3 4 5) (6 7 8) (9 :a :b)) ; actual behavior

(partition 3 3 [:a :b :c] (range 9))
; => ((0 1 2) (3 4 5) (6 7 8)) ; actual behavior

(partition 3 1 [:a :b :c] (range 5)) ; suspected bug here
; => ((0 1 2) (1 2 3) (2 3 4) (3 4 :a)) ; actual behavior
; => ((0 1 2) (1 2 3) (2 3 4)) ; not actual behavior, but that's what I expect.

Does it make sense to you?

(partition 3 1 [:a :b :c] (range 5))
;; ((0 1 2) (1 2 3) (2 3 4) (3 4) (3))
;;  ^_____________________^ ^_______^
;;  complete partitions     those are incomplete
;;  each of size 3          size != 3
;;  each at offset apart    each at offset apart

but also my english skills are not sharp enough to suggest the wording for clojure.core )

I just tried to give my personal understanding of the function

I see ... but in practice, it is useless to return (3 4 :a) because 3 and 4 were already returned in the previous partition. So IMHO, it is still fishy/buggy.

this is still useful in case nil-padding is not desired (which makes usage of partition-all useless) something like (partition 3 1 (repeat 2 :n-a) '(1 nil 3 nil 4 nil 5 nil 6 nil)) here I want to clear the difference between nil value coming from my list and an indicator of absence of value because “not enough elements to fill the partition”

I would want and expect current behavior. It seems fishy because the partitions are overlapping and you are thinking of items not “windows”. I rely on this behavior to give me a sliding window over a seq that fills in the tail.

@favila are you using different values for n and step ? I want to make sure that we are talking about the same thing.

So in your example, every element that would be collected by “step” defines a partition

If there are less than n items left after it, it is normally dropped, unless enough pad is supplied

> I see ... but in practice, it is useless to return (3 4 :a) because 3 and 4 were already returned in the previous partition. So IMHO, it is still fishy/buggy.

I’m saying no, because 3 was not in the first position of the previous partition

If the function was following this logic, there should be another partition (4 :a :b) after that

I actually expect an additional (4 :b :c), I’m not sure why there isn’t one

I guess the logic is you will only get one incomplete partition

And yeah, that breaks how I use partition for windowing if n>2

So we agree that there is a problem, there?

Yeah but we have opposite conceptions of what is the correct behavior :)

i don’t think current behavior violates the doc though. I just would like it to go further

But definitely the “step” not “n” defines the partitions, not whether an item was consumed

Please file a problem on http://ask.clojure.org