Re: 'get' behaviors
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, > 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
Re: 'get' behaviors
On Mon, May 29, 2017 at 1:20 PM, 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?focusedCommentI
>> d=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 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 e
Re: 'get' behaviors
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.
Issue #2 is logged as CLJ-700 and is currently on the roadmap for 1.9
> (altho it's been postponed for a few releases already so it might happen
> again)
>
Noted, thanks.
>
> 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.
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 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.
Re: 'get' behaviors
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
Issue #2 is logged as CLJ-700 and is currently on the roadmap for 1.9
(altho it's been postponed for a few releases already so it might happen
again)
I'm not aware of any previous discussion on Issue #3 but IMO this is
consistent with clojure's GIGO behaviour
On 29/05/17 19:15, rebor...@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:a1:b2)"a""not found");; ClassCastException
#2
'get' is happy with other transients (namely vectors and maps) but
fails silently on sets:
(get(transient#{012})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 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
<mailto:clojure+unsubscr...@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 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.
'get' behaviors
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 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.
