Good dog morning
I got that dog in me
God morning. Anyone want a badly distributed random integer 1..100?
bb -e '(with-open [r (java.io.FileInputStream. "/dev/urandom")] (mod (int (+ (.read r) (.read r))) 100))'Why not use the facilities in test.whatever to generate random things? Of course, that would not be as interesting, but could get you to somewhere both faster and more correctly
My purpose for engaging with small snippets like this is to learn and to practice, not to solve it quickly. I'd welcome a test.whatever-solution too, I would probably learn more!
I have no clue what test.whatever refers to ๐
https://clojure.github.io/test.check/clojure.test.check.generators.html
Like https://clojure.github.io/test.check/clojure.test.check.generators.html#var-bind
or https://clojure.github.io/test.check/clojure.test.check.generators.html#var-choose
If thereโs any somewhere in this case, itโs to a random number. (rand-int 100) seems like the most obvious competitor?
:)
exactly what I was hoping for this morning! ๐
I fail to explain if this is badly distributed!
(defn get-number []
(with-open [r (java.io.FileInputStream. "/dev/urandom")]
(mod (int (+ (.read r) (.read r))) 100)))
(into (sorted-map)
(update-vals (group-by identity
(repeatedly 10000 get-number))
count))
looks quite even to me?Haha. Iโll need to try. Was thinking that 512 isnโt 500, so expected some skew.
aaah. urandom only gives 0 to 255.
(defn urandom []
(with-open [r (java.io.FileInputStream. "/dev/urandom")]
(.read r)))
(def nums (repeatedly 10000 urandom))
(def stats (into (sorted-map) (frequencies nums)))
((juxt first last) stats)
;; => [[0 42] [255 44]]Your summation also introduces some skew! The sum of the two urandom picks will have 255 as the most likely pick (255 combinations) and 510 and 0 to be the least likely (each has one possible pick). Then the mod 100 does (something) afterwards.
I think filtering for < 200 may be the way to go.
to what aim, if I may ask?
Ah, I believe I understand what you mean. Sample, cut "outside" values, mod the inside. Makes sense!
The + is still a source of skew, though.
I did a different, roundabout, worse thing: just sample more small urandom numbers to make big Clojure numbers. Then it's not such a big deal to get the "bad" values that could have been filtered.
(defn urandom [n]
(with-open [r (java.io.FileInputStream. "/dev/urandom")]
(doall (repeatedly n #(.read r)))))
(defn normalize-map-values [m]
(let [total (reduce + (vals m))
average (/ total (count m))
avg-inverse (double (/ 1 average))]
(update-vals m (partial * avg-inverse))))
(->> (urandom 100000)
(partition 2)
(map (fn [[x y]] (+ (* 256 x) y)))
(map #(mod % 100))
frequencies
(into (sorted-map))
normalize-map-values
(take 10))
;; => ([0 1.046]
;; [65 1.048]
;; [70 1.028]
;; [62 0.926]
;; [74 0.9520000000000001]
;; [7 1.012]
;; [59 0.99]
;; [86 1.018]
;; [20 0.9540000000000001]
;; [72 0.964])off to get some sun. Have a nice day, Peter!
I was a tad unclear. Filtering was instead of adding. ๐
then we are in complete agreement, my Swedish friend!
(with-open [r (java.io.FileInputStream. "/dev/urandom")]
(mod (->> #(.read r)
repeatedly
(filter #(< % 200))
(take 1)
doall
first)
100))
exactly!