Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rationale question #12

Open
MasonProtter opened this issue Mar 4, 2020 · 2 comments
Open

Rationale question #12

MasonProtter opened this issue Mar 4, 2020 · 2 comments

Comments

@MasonProtter
Copy link
Member

could you clarify in what situations this package is preferable to just using Iterators.partition?

@tkf
Copy link
Member

tkf commented Mar 5, 2020

Iterators.partition is useful when you want to implement, e.g., foreach on arrays. This package does not try to replace it.

This is essentially just an API I extracted out from Transducers.jl as I thought it may be useful for someone else as well. It's also easier to ask collection implementers to add support for halve (as they don't need to add Transducers.jl to their dependencies).

Although halve is more-or-less a special case of partition (well, exactly so for arrays), the requirements for halve is more relaxed than partition. I think it has some benefits. Since the resulting length doesn't have to be exactly half (or within +/- 1), it makes implementation cheaper for something like AbstractString and Iterators.product. It is also possible to implement this API for iterators "with computation" like Base.Generator and Iterators.Filter. (But I'm not doing this since treating it via transducers is much better for me.) I haven't looked into yet, but I think halve is much easier to implement for sets and dicts.

@MasonProtter
Copy link
Member Author

I see, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants