Skip to content
This repository has been archived by the owner on Sep 1, 2020. It is now read-only.

mergesorted - function to merge together 2 sorted iterators #62

Closed
wants to merge 1 commit into from

Conversation

dfdx
Copy link
Contributor

@dfdx dfdx commented Jun 5, 2016

Function to merge 2 sorted iterators of unique values. Example:

it1 = [:a, :c, :d, :f]
it2 = [:b, :d, :e]
merged = mergesorted(it1, it2)
collect(merged)  # ==> [:a, :b, :c, :d, :e, :f]

(Note that :d presents in both iterators, but only single occurrence is emitted)

* if hd1 < hd2, hd1 is emitted
* if hd1 > hd2, hd2 is emitted
* if hd1 == hd2, hd1 is emitted and hd2 is discarded (so no duplicates
is produced)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, thanks.

@dfdx dfdx force-pushed the mergesorted branch 2 times, most recently from e8e8069 to 7771bde Compare June 5, 2016 18:27
@dfdx
Copy link
Contributor Author

dfdx commented Jun 5, 2016

I noticed that tests were failing for Julia 0.5, so I've rewritten them to be more similar to existing ones. I also modified next function to make it easier to analyze.


function next(it::MergedIter, s::MergedState)
lt = it.lt
if done(it, s) throw(ArgumentError("Iterator is done")) end
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We usually do not throw an error for calling next after done

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really have a strong opinion here, but I'm curious what's the conventional approach to handle next() after done(...) == true?

I know that for objects like ranges we can just continue producing new elements. However, for IO-based iterators (e.g. iterator over a file) we can't really produce anything else after the end of EOF. So what is supposed to be an appropriate result for calls to next() for such iterators?

(In fact, I'm working on one such iterator right now, so would be glad to make it using best practices)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The conventional approach is to assume that one only calls next after having called done before to make sure that the iterator is not terminated.

@dfdx dfdx mentioned this pull request Jun 6, 2016
@dfdx
Copy link
Contributor Author

dfdx commented Jun 6, 2016

Please, check #63 for a version of PR that takes into account some of comments in this thread.

@dfdx
Copy link
Contributor Author

dfdx commented Jun 8, 2016

Closing as the least valuable implementation, see improved versions in #63

@dfdx dfdx closed this Jun 8, 2016
@dfdx dfdx deleted the mergesorted branch June 9, 2016 06:57
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants