3 ms·
You seem to have reframed the discussion from "horribly inefficient" as defined by extraneous operations, to one of raw speed. I'm certain I've never claimed t
by fogus 16y ago
You seem to have reframed the discussion from "horribly inefficient" as defined by extraneous operations, to one of raw speed. I'm certain I've never claimed that a tail-recursive implementation couldn't produce faster times. My statement from the beginning has been that recursion is a low-level operation. I stand by that statement. My combinator post provided 3 useful functions that could prove useful in the future. Your `recle4` implementation does one thing only. If any one of the functions in my combination gains speed, then my implementation will likewise gain speed. This leaves room for optimization without having to dive right into creating a convoluted recursive implementation. I'm pretty sure the words "avoided if at all possible" subsumes the need to optimize if every ounce of speed is required. Raw execution speed is not the only unit of speed that we should consider. We shouldn't sacrifice the speed of the developer or the speed of comprehension just to placate our lizard brains.
- ohyes 16y agoI have not done any reframing whatsoever. You never framed the conversation to begin with. You said, point blank, that composition is better than recursion in functional languages. Better. I called BS. How, exactly, then, do you define 'better'? You didn't give an operational definition of 'better' (which is your responsibility, not mine), so I made up my own. If you don't like it, then be more careful with your claims. It certainly is not 'better' in all meanings of the word. (at least any of those that are clearly defined or measurable for me. In retrospect I see that you were talking about 'style' but 'style' is pretty impossible to measure as it is entirely subjective). .. I wrote a similar function in the same language, and it was twice as fast as yours. Your function, therefore, wastes operations. (At least twice as many, approximately). That isn't a small amount! I'm not even serious about Clojure and my solution seems pretty straightforward. Unless all recursion is rocket science, it is very simple recursion. (Granted I had to RTFM to write it and I suppose a proper name might help, but it would help your implementation too). Why do I need dozens and dozens of ravioli functions that I'm just going to forget that I implemented clutter my name-spaces? Please, for the love of God, at least use a letfn/flet/labels. What is the next developer going to do when I am dead or have retired to my private island? He'll have to learn, not one, but 3 different functions, and know what they do. None of your composed functions are particularly self explanatory. In what way do you think you will get a 2x improvement through the improvement of other functions? I suppose if you write a new compiler for Clojure (perhaps a sufficiently smart one?), it could happen, but you will not get that type of improvement simply by improving the 'pack' function, for example. The way that you are going about collecting the values is fundamentally opposed to efficiency. 'Creating homogeneous groupings then counting the size of those groups' (what you did) is going to be slower than 'counting consecutive same things' (what I did). This isn't really about raw efficiency, this is about a fundamentally broken thought process used to describe the algorithm. That broken thought process is a result of attempting to shoehorn the answer into the realm of functional composition. Anyway, I respectfully disagree.
- fogus 16y agoNext time before you go off on a tirade against my so called claims, go back and check your facts. I did not say "better". Whomever submitted my post did. You have interesting ways of respectfully disagreeing with people.