New package: LazyMaps v0.2.1
- Registering package: LazyMaps
- Repository: https://github.com/emmt/LazyMaps.jl
- Created by: @emmt
- Version: v0.2.1
- Commit: 2aeeb3c67647bafe2b0b95bf5bd08e57e84254ad
- Reviewed by: @emmt
- Reference: https://github.com/emmt/LazyMaps.jl/commit/2aeeb3c67647bafe2b0b95bf5bd08e57e84254ad#commitcomment-160554445
- Description: LazyMaps provide mapping of functions to arrays or collections with deferred evaluation
Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.
1. New package registration
Please make sure that you have read the package naming guidelines.
2. AutoMerge Guidelines are all met! ✅
Your new package registration met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.
3. To pause or stop registration
If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.
Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.
I wonder how it compares to mapview(f, A) from FlexiMaps.jl? Would be nice to have such a comparison in the README (or make a PR if there's some minor thing missing :) ).
Also https://github.com/JuliaArrays/MappedArrays.jl and https://github.com/JuliaArrays/LazyArrays.jl
Thank you for pointing these. I was not aware of FlexyMaps.jl although, sometime ago, I had a look at the 2 others and decided that they could not really meet my needs. I wanted a lightweight package to implement lazy maps (of arrays or collections) for my under development new version of LazyAlgebra, one requirement is to be able to make lazy mappings of arrays work on CPUs as well as on GPUs.
But you are right, I have to make sure of this. For example, I've just looked again and BroadcastArray(f, A) in LazyArrays is in fact close to lazymap(f, A) in LazyMaps and shows impressive preformances.
In the comming days I will investigate these other possibilities...
This pull request has been inactive for 30 days and will be automatically closed 7 days from now. If this pull request should not be closed, please either (1) fix the AutoMerge issues and re-trigger Registrator, which will automatically update the pull request, or (2) post a comment explaining why you would like this pull request to be manually merged. [noblock]
This pull request has been inactive for more than 30 days and has automatically been closed. Feel free to register your package or version again once you fix the AutoMerge issues. [noblock]
I wonder how it compares to
mapview(f, A)from FlexiMaps.jl? Would be nice to have such a comparison in the README (or make a PR if there's some minor thing missing :) ).
I takes a while but I made a comparison of the different existing possibilities. mapview(f,A) from FlexiMaps is indeed very similar to lazymap(f, A) and has nice additional features (dictionaries, etc.). The results of my tests (and benchmarks) are summarized at the end of this README.md.
However, with FlexiMaps, there is no equivalent to lazymap(T, f, A) to specify an element type for the mapped view and directly build a FlexiMaps.MappedArray with a given element type yields an abstract array whose eltype is not the type of the result returned by getindex while lazymap takes care of converting this result correctly. Among the other tested packages, only BroadcastArray{T}(f, A) using LazyArrays provide.
Also, in FlexiMaps, there is no shortcut to build a read-only view when the inverse function is known. This is simply done by lazymap(f,A,throw) in LazyMaps.
Finally, FlexiMaps has currently a compat bound of Julia ≥ 1.10 which I would like to relax because I have real-time software running on a solar telescope that currently works on an older Julia version and I do not want to break it.
I'd be happy to make a PR to add these features in FlexiMaps but the element type issue is quite a breaking change, it implies that for B = mapview(T, f, A), the expression B[i] is evaluated as convert(T, f(A[i]))::T or something similar (this changes nothing to evaluate B[i] = x). @aplavin What do you think?
Thanks @emmt!
Sounds like a couple of specific but common usecases that are definitely supported by mapview() – but can use a more explicit mention in the docs. Let me know if there's more, so that I could add examples to the docs :)
with FlexiMaps, there is no equivalent to lazymap(T, f, A) to specify an element type for the mapped view
One doesn't need extra syntax/arguments for that. mapview(x -> convert(T, f(x)), A) works exactly as one would expect.
Also, in FlexiMaps, there is no shortcut to build a read-only view when the inverse function is known.
You mean shorter than mapview(x -> f(x), A)? Seems quite concise for me :)
FlexiMaps has currently a compat bound of Julia ≥ 1.10 which I would like to relax
It supported Julia 1.6+ until [email protected]. Then I bumped Julia compat indeed, old Julia versions aren't officially supported now anyway. But I'm definitely open to PRs that expand Julia/package compat, that's not a fundamental issue.