Can anyone explain the following - whether it's a bug in org.clojure/math.combinatorics? or not?
(require '[clojure.math.combinatorics :as combo])
(defn order-preserving-combinations
[a]
(filter
(fn [c]
(= a (flatten c)))
(combo/partitions a)))
(let [a (order-preserving-combinations [7 4 2 1 3 2 6 3 4])
b (order-preserving-combinations [7 4 2 1 3 2 6 3 3])]
(print "a" (count a) "b" (count b)))
The length of a is 0 while the length of b is 8 - live journal repl at https://nextjournal.com/xlfe/bug-in-orgclojuremathcombinatorics-?you have an expectation that the partitions will retain the same order across all of the partitions as the original collection?
I think (combo/partitions a)
doesn't guarantee order and so (= a (flatten c))
is false. Hence (order-preserving-combinations [7 4 2 1 3 2 6 3 4])
is empty
ah right. I need only the partitions that are in the same order as the original array, hence the filter. hmm
what I found weird was that b works but a doesn't. (consistently)
given that combo/partitions doesn't guarantee order, what's the best way to get all partition combination that do preserve order?
thanks indy
I don't know enough about what partition is supposed to do to say, but it is interesting there is a different algorithm for a unique collection of items than when there's a collection with duplicates, https://github.com/clojure/math.combinatorics/blob/master/src/main/clojure/clojure/math/combinatorics.cljc#L943
either way, it doesn't seem like order matters in a partition:
> (->> (combo/partitions [7 4 2 1 3 2 6 3 4])
(filter #(= 1 (count %))))
(([7 4 4 2 2 1 3 3 6]))
Has anybody ever used dear imgui
in clojure? I've found these java bindings for it https://github.com/SpaiR/imgui-java but no clojure ones
In any case I'm not sure how to build java interop with this specific part of the example they give:
public static void main(String[] args) {
launch(new Main());
}
how does this translate in Clojure? https://github.com/SpaiR/imgui-javaNevermind, I accidentally managed 😄
Hi, I've got a question about code style and best practices. The inspiration to this question is the saying that it is better to have 100 functions to operate on one data structure than 10 function that operate on 10 data structures. Have a look at the below example:
(defn process [{:keys [_get-rate-fn] :as opts} txs]
(let [opts (merge {:report-currency "GBP" :precision 4} opts)]
(-> {:txs txs}
(process-common/coerce-data)
(process-common/fetch-rates opts)
(process-common/add-totals)
(process-common/convert-currency opts)
(process-common/calc pl-rules)
(process-common/calc-summary))))
There is a process
fn containing a pipeline of operations. All starts from a map holding one key: txs
, which is a collection of data. Let's call it map-at-hand, and in the output there is the same map-at-hand but modified and extended (holding same txs
but coerced, modified, plus extra data like what rates are used, and the results of rules calculation for the given report).
The question is about passing parameters to each step in pipeline. Some of them take one argument (only that map-at-hand), some of them two where the second is the opts
(holding stuff like :report-currency, digits precision, or the data source for rates).
I was wondering, wouldn't be better to just merge that map and opts
into one map passed through the steps, kind of a context that changes each step.
On the one hand some of the functions might have access to data they don't need, on the other hand, it is just easier to manage and there is no problem with positional arguments.
What are your thoughts on this?Imo it becomes painful when the functions you use don’t have the same conventions: The data map sometimes in 1st, sometimes in 2nd position. The options being passed sometimes as a map, sometimes as positional arguments. Etc. Your example has a convention: data in first arg, optional arguments in a map as 2nd argument. It looks fine to me.
Merging both maps in one has additional problems: How to separate the actual data (that might need to be sent back in an http response, or stored in a db) and the optional arguments.