Hi, thanks for the clarification. Not sure #3 is worth a Jira either, is perhaps useful for a few and there are more important things I guess. #2 is a work in progress already and #1 it's by design. I'm just happy it is noted somewhere such as here and clojuredocs (done).
Thanks Renzo On Monday, 29 May 2017 22:21:59 UTC+1, Andy Fingerhut wrote: > > > > On Mon, May 29, 2017 at 1:20 PM, <rebo...@gmail.com <javascript:>> wrote: >> >> On Monday, 29 May 2017 18:45:20 UTC+1, Nicola Mometto wrote: >>> >>> Issue #1 had been logged in CLJ-1242, but it was later decided to just >>> focus on making equality not throw as contains/get throwing is consistent >>> with java behaviour, see comments from Stu and Alex here >>> https://dev.clojure.org/jira/browse/CLJ-1242?focusedCommentId=40612&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-40612 >>> >> >> Mmmh, I see. I've also seen now that by forcing compare semantic the tree >> search can stay O(logN) average. Removing the compare constraint would make >> the search O(n/2) avg. So there is a point I guess. >> > > I believe it is O(log N) worst case, as well as average case, via a > balanced binary tree implementation. > > >>> I'm not aware of any previous discussion on Issue #3 but IMO this is >>> consistent with clojure's GIGO behaviour >>> >> >> It's kind of border line, because the doc refers to "map" and "key" as >> arguments but then it can also handle other associative things like >> vectors. nth correctly handles the outofbound. Perhaps get should do the >> same. >> > > I have noticed this behavior before, but not brought it up in the group, > since my guess is that a programming mistake leading to an actual bug here > seems unlikely (i.e. you wouldn't accidentally get there from sequentially > walking through a list starting at 0 and incrementing by 1, because you'd > pretty much always hit the end of the vector/list/etc. first). That and > the GIGO behavior that Nicola refers, and a focus on performance, combine > to mean it is unlikely that any change would be made to Clojure that leads > to a longer execution time for get when the index is in range (unlikely is > my guess -- I am not a person who makes these decisions, but have seen > several made in this direction before over the years). > > It may be more likely that the Clojure core team would be willing to > accept a change to clojure.spec that would check for such erroneous inputs > to get. If you are interested, you could try creating a JIRA ticket for a > change like that. You could mention in the ticket that a change to > clojure.core/get might be interesting, if someone can think of a way that > has no performance impact in the non-error case. > > Andy > > > >> My 2C >> Thanks >> >> >>> >>> On 29/05/17 19:15, rebo...@gmail.com wrote: >>> >>> I was wondering if the following 'get' behaviors are worth a chat. >>> Apologies if this is known issue, but they don't seem impossible corner >>> cases to me. >>> >>> #1 >>> >>> This one looks read-only access to me and I'm not sure why a suitable >>> comparator should be in place. >>> >>> (get (sorted-map :a 1 :b 2) "a" "not found");; ClassCastException >>> >>> #2 >>> >>> 'get' is happy with other transients (namely vectors and maps) but fails >>> silently on sets: >>> >>> (get (transient #{0 1 2}) 1);; nil >>> >>> #3 (.intValue x) can throw away bits with precision loss. Sufficiently >>> large keys produce the following: >>> >>> (get ["a" "b" "c"] 4294967296) ;; "a" >>> >>> Thanks >>> Renzo >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@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+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
