[#67346] Future of test suites for Ruby — Charles Oliver Nutter <headius@...>
I'll try to be brief so we can discuss all this. tl;dr: RubySpec is
19 messages
2015/01/05
[#67353] Re: Future of test suites for Ruby
— Tanaka Akira <akr@...>
2015/01/05
2015-01-06 7:18 GMT+09:00 Charles Oliver Nutter <[email protected]>:
[#67444] [ruby-trunk - Feature #10718] [Open] IO#close should not raise IOError on closed IO objects. — akr@...
Issue #10718 has been reported by Akira Tanaka.
3 messages
2015/01/09
[#67689] Keyword Arguments — Anthony Crumley <anthony.crumley@...>
Please forgive my ignorance as I am new to MRI development and am still
5 messages
2015/01/20
[#67733] [ruby-trunk - Bug #10761] Marshal.dump 100% slower in 2.2.0 vs 2.1.5 — normalperson@...
Issue #10761 has been updated by Eric Wong.
4 messages
2015/01/21
[#67736] Re: [ruby-trunk - Bug #10761] Marshal.dump 100% slower in 2.2.0 vs 2.1.5
— Eric Wong <normalperson@...>
2015/01/22
[email protected] wrote:
[#67772] Preventing Redundant Email Messages — Jeremy Evans <code@...>
For a long time, I've wondered why I sometimes receive redundant email
5 messages
2015/01/23
[ruby-core:67544] [ruby-trunk - Feature #10730] Implement Array#bsearch_index
From:
radan.skoric@...
Date:
2015-01-12 13:56:52 UTC
List:
ruby-core #67544
Issue #10730 has been updated by Radan Skori=C4=87.
>=20
> I'm neutral to Array#bsearch_index, but how handy is it? Symmetry/consis=
tency is not a good reason for Ruby design.
Let me then tell you about my use case. There is a sparse array of dates an=
d I want to slice out a part of it that falls within minimum and maximum da=
te. It is then later used to retrieve same values associated with those dat=
es for displaying a chart. In another use case, you have to find a first el=
ement that matches the criteria and then take next N elements to display th=
em. Bsearch index would make both concies and also very fast oneliners:
ary.slice((ary.bsearch_index {|e| e>=3Dmin} || 0) .. (ary.bsearch_index {|e=
| e>=3Dmax} || ary.size))=20
ary.slice(ary.bsearch_index { |e| predicate(e) }, N)
When implementing it, I knew about bsearch and I actually just kind of assu=
med I also have bsearch_index and was surprised it's not there. That is wha=
t made me go check the ruby source and see if I can actually add the method=
in a simple way.=20
So the biggest reason why IMHO we need either BOTH or NONE is the principle=
of least surprise and not symetry or consistency.
But then again, maybe it's just me and not many other people would get the =
same idea. I'm open to being wrong on that point :)
>=20
> http://stackoverflow.com/questions/23481725/using-bsearch-to-find-index-f=
or-inserting-new-element-into-sorted-array
>=20
> shows a somewhat reasonable use case, but the insert takes O(n). Is it o=
kay? When you have to modify the array that is used for bsearch, rbtree ge=
m might be a better choice; both search and insert take O(log n).
>=20
Yes, I agree with you, that is not the best use case. However it shows how =
that person also thought that exact method will be there.
P.S. Bye the way, thanks for taking the time to discuss this issue. :)
----------------------------------------
Feature #10730: Implement Array#bsearch_index
https://bugs.ruby-lang.org/issues/10730#change-50957
* Author: Radan Skori=C4=87
* Status: Open
* Priority: Normal
* Assignee:=20
----------------------------------------
We currently have Array#bsearch but no Array#bsearch_index and to me it see=
ms that violates the principle of least surprise, especially when we consid=
er the other combinations of existing methods that find either an element o=
r it=E2=80=99s index.
For example: the method would be very useful when needing to slice out a pa=
rt of a sorted array. It would allow very quick location of the indices of =
the beginning and end of the segment.
A quick google of =E2=80=9Cruby bsearch_index=E2=80=9D reveals that I am no=
t the only one that needed and expected that function to exist:
http://stackoverflow.com/questions/23481725/using-bsearch-to-find-index-for=
-inserting-new-element-into-sorted-array
http://stackoverflow.com/questions/8672472/is-there-a-built-in-binary-searc=
h-in-ruby
https://github.com/tyler/binary_search#usage
The very good thing is that we can get that method almost for free since th=
e current implementation of bsearch internally finds the index and then loo=
ks up the actual element.
I have opened a PR on the github mirror that adds bsearch_index in what see=
ms to me the simplest way possible: https://github.com/ruby/ruby/pull/813 .=
=20
I changed the bsearch implementation into bsearch_index and based the bsear=
ch on it.=20
Please Note: The diff is deceptively large, if you look carefully you will =
notice that the change is actually small and the actual binary search algor=
ithm remained completely intact.=20
I have kept the behaviour documentation on bsearch and simply referenced it=
from bsearch_index to minimize the documentation changes.
--=20
https://bugs.ruby-lang.org/