On Mon, Feb 15, 2010 at 8:45 AM, George . <clojuri...@gmail.com> wrote: > Currently, if you want to perform a range query on a sorted-seq (AKA > PersistentTreeMap), you are are advised to use the subseq wrapper for > seqFrom. > > For instance, let's say your keys are dollar values you could do (subseq > my-map > 30) to get all entries with keys greater than 30 or (subseq my-map >> 30 < 100) to get all entries with keys that range between 30 and 11. The > former case is O(logN) as it is entirely delegated to the logarithmic > seqFrom method. However, the latter example has worst case O(N) behavior > since subseq is doing a take-while after .seqFrom. > > Is there any plan to support upper bounds directly within seqFrom in order > to make the worst-case behavior logarithmic all around? > > If not, would such a patch even be considered or is the simplicity of > implementation an overriding factor? > >
I'm confused. Do you want something other than a seq of values in range as a result? Because if there are K things in range, there is no way to consume them in complexity less than O(K). That cost won't be incurred until you consume them, due to take-while being lazy. OTOH, if what you want is a subset or submap, or, from them, a constant-time count, well, that's a different function altogether. I'm not opposed to subset or submap proposals. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
