You don't increase the performance by limiting the input value range in a
pre-condition.
On Thursday, February 19, 2015 at 12:52:38 PM UTC+1, Cecil Westerhof wrote:
I have the following function:
(defn lucky-numbers
Lucky numbers from 1 up-to upto-value.
1 = upto-value =
I have the following function:
(defn lucky-numbers
Lucky numbers from 1 up-to upto-value.
1 = upto-value = 10.000.000
http://en.wikipedia.org/wiki/Lucky_number;
; doc-string and pre-condition should match
[upto]
{:pre [(= upto 1)
(= upto (* 10
Fluid Dynamics a2093...@trbvm.com writes:
(defn lucky-numbers
([upto]
(lucky-numbers false upto))
([no-max-check upto]
{:pre [(if no-max-check true (= upto (* 10 1000 1000)))]}
;; code as before
))
Why not (or no-max-check (= upto (* 10 1000 1000)))?
On Thursday, February 19, 2015 at 9:54:21 AM UTC-5, Tassilo Horn wrote:
Cecil Westerhof cldwes...@gmail.com javascript: writes:
Hi!
At the moment the following:
(lucky-numbers 1001)
gives:
AssertionError Assert failed: (= upto (* 10 1000 1000))
user/lucky-numbers
But
one approach would be a multi-method for the condition check that doesn't
enforce the limit on BigInt
user= (defmulti lucky-numbers-limit type)
#'user/lucky-numbers-limit
user= (defmethod lucky-numbers-limit :default [n] ( 0 n 1001))
#MultiFn clojure.lang.MultiFn@7533f6b5
user= (defmethod
Cecil Westerhof cldwester...@gmail.com writes:
Hi!
At the moment the following:
(lucky-numbers 1001)
gives:
AssertionError Assert failed: (= upto (* 10 1000 1000)) user/lucky-numbers
But I would like the following to be executed:
(lucky-numbers :no-max-check 1001)
How would I
