The recur expression must match the arity of the recursion point exactly.

You're trying to recur into another function, even though it looks like the same function, you're creating two functions that differ by arity

And you can't recur into the other one

You need to merge both of them into the two arity one, and then make the one-arity a call to the two-arity

Ended up with

(defn digits
  ([remaining-digits]
   (digits remaining-digits 1))
  ([remaining-digits digits-so-far]
   (if (= (quot remaining-digits 10) 0)
     digits-so-far
     (recur (quot remaining-digits 10) (inc digits-so-far)))))

Yes, that's how you do it

You can alternatively use the loop/recur syntax. Typically, calls to the two arity function will be internal so you can avoid exposing it.

If you don't particularly care about performance, you could just define it like this 😛:

(defn digit-count [n]
  (count (str (Math/abs n))))

@U883WCP5Z That's how I did it initially. This is for exercism. My mentor said to do it arithmetically. I wonder, truly though, how much more/less performant each version is

Well, here they are:

user=> (defn digits2 [n]
  #_=>   (loop [num (long n)
  #_=>          d 1]
  #_=>     (let [q (quot num 10)]
  #_=>       (if (zero? q)
  #_=>         d
  #_=>         (recur q (inc d))))))
#'user/digits2
user=> (defn digits1 [n]
  #_=>   (count (str (Math/abs (long n)))))
#'user/digits1
user=> (crit/quick-bench (digits1 1234567890123456789))
Evaluation count : 7296390 in 6 samples of 1216065 calls.
nil
             Execution time mean : 75.719094 ns
    Execution time std-deviation : 2.568614 ns
   Execution time lower quantile : 72.614107 ns ( 2.5%)
   Execution time upper quantile : 78.657657 ns (97.5%)
                   Overhead used : 9.051454 ns
user=> (crit/quick-bench (digits2 1234567890123456789))
Evaluation count : 15884838 in 6 samples of 2647473 calls.
nil
             Execution time mean : 28.911209 ns
    Execution time std-deviation : 0.276928 ns
   Execution time lower quantile : 28.680677 ns ( 2.5%)
   Execution time upper quantile : 29.357405 ns (97.5%)
                   Overhead used : 9.051454 ns

Found 1 outliers in 6 samples (16.6667 %)
	low-severe	 1 (16.6667 %)
 Variance from outliers : 13.8889 % Variance is moderately inflated by outliers

Wow, thank you for that. Super interesting, ok so now we know it's definitely slower the way I was doing it

Thanks, that's exactly what I ended up doing

hehe, you are right, depends on your definition

I’d say that counting the digits in 0 yields 1 digit, so should also be included

maybe https://github.com/metabase/toucan is the closest thing to that.

Yeah seems pretty close. Thanks for that!

Renamed to #books-clojure-applied

Ok, so I have decided to reimplement range

(defn irange [start end]
  (let [direction-positive (if (< start end) true false)
        end-operator (if direction-positive > <)
        jump-operator (if direction-positive inc dec)]
    (loop [x start
           l []]
      (if (end-operator x end)
        l
        (recur (jump-operator x) (conj l x))))))

That is a reasonable-looking implementation. I only wanted to point out that if you call range with the appropriate parameters inside of irange you can take advantage of performance optimizations of range , e.g. it is lazy, and I believe more efficient in its memory and CPU usage than your implementation above.

something like that maybe:

(defn irange-2 [start end]
  (let [direction-positive? (< start end)]
    (if direction-positive?
      (range start (+ end 1))
      (range start (- end 1) -1))))

(nitpicking: (inc end) and (dec end) read more natural to me)

I’d also point out that you can call range with 0-3 arguments, maybe you want to also implement the 3 argument version (`start` end step )

@UDF11HLKC I was just tailoring it for one of the advent of code excersises, so I consider this "one-off". Plus step seems unintuitive considering negative numbers. I would much rather change the implementation to accepting a partially applied function as step - seems more natural to me, but I am noob so :)

Right, if its a one off then sure ^^

I spent a couple months implementing the current version of range in core. I felt somewhat insane after a while just doing nothing but counting numbers more efficiently but there are a surprising number of weird edges and perf optimizations

now I am intrigued, the implementation is in the runtime?

https://github.com/clojure/clojure/blob/4ef4b1ed7a2e8bb0aaaacfb0942729252c2c3091/src/jvm/clojure/lang/LongRange.java

Well that’s all the most optimized one for all longs

You can use range with any kind of number - rationals, doubles, bigintegers, and even mix them

Consider long steps that are a high percentage of the long range etc - lots of overflow cases

The long range has to support 3 different iteration styles - self reduce (highly optimized), chunked seqs, and unchunked seqs

Balancing all that was a challenge

And we were really trying to improve the existing common case, and add the optimized reduce behavior, and not break anything that worked in the much simpler prior impl

what made you tackle performance of range? You’d say that is not the most ‘hot’ code to be found

And it has to be thread safe (which I broke in one very subtle case and had to fix)

range is used in lots of places for very small ranges, and people use for a huge set of examples

But really it was part of a broader effort when we introduced transducers to make some of the key seq generator functions self reducible (range, iterate, cycle)

https://clojure.atlassian.net/browse/CLJ-1515 for the gory details

fascinating!

a class of problems I hope to be dealing with some day

Wait, re-implementing range was better than doing (range 2 -3 -1) ?

I think it is more accurate to say "they preferred a different API that matched the way they wanted to pass parameters, versus what range provides"

as Andy said, (range 2 -3 -1) returns (2 1 0 -1 -2), so now i need to append one more value by extending the range, again I have to do yet another if for which parameter i have to dec/inc and so and so

Oh, okay, but still, why re-implement range and not just wrap it behind the interface you want say:

(defn rng
  [s e]
  (if (<= s e)
    (range s (inc e))
    (range s (dec e) -1)))

Which is one of my earlier suggestions in this thread

not the code, but the suggestion of calling range

Oh okay, hadn't seen that

I did always think it would be cool if range took an option to specify the bounds

But then again, its so easy to just modify to wtv bound you most care about

I think the default bounds are designed for zero based index iteration over collections.

yes, i noticed range is mostly for iterating zero-index things, as for your solution it seems fine and better 🙂 #beginners but you have more conditions, you will be (dec end) or (inc end) based on wether its negative or positive, so it still different code I think.

Haha, ya sorry. I sounded a bit surprised, but it was mostly that I thought no one else had suggested to just leverage the existing range instead of re-implementing it, which I was wrong since others had I just overlooked it.

What do you mean?

(rng 5 1)
;; => (5 4 3 2 1)
(rng 2 -3)
;; => (2 1 0 -1 -2 -3)
(rng 1 4)
;; => (1 2 3 4)
(rng 0 -3)
;; => (0 -1 -2 -3)
(rng 2 2);; => (2)

yep, I was doing(repling) the same, yep works as intended great, thanks

🙂

There's also https://github.com/aphyr/tea-time

have you looked at #braveandtrue ?

Not yet