-
Notifications
You must be signed in to change notification settings - Fork 476
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
New package: IsPositive v1.0.0 #102561
New package: IsPositive v1.0.0 #102561
Conversation
JuliaRegistrator
commented
Mar 8, 2024
- Registering package: IsPositive
- Repository: https://github.com/putianyi889/IsPositive.jl
- Created by: @putianyi889
- Version: v1.0.0
- Commit: 4f7158517988ea3453e4da1800c0c1550e203927
- Reviewed by: @putianyi889
- Reference: putianyi889/IsPositive.jl@4f71585#commitcomment-139572433
UUID: b2621e3c-9d78-409a-a956-21e401f7880f Repo: https://github.com/putianyi889/IsPositive.jl.git Tree: 4cfaef64e301f64a5ea34809955d6325562a322d Registrator tree SHA: 17aec322677d9b81cdd6b9b9236b09a3f1374c6a
Your Since you are registering a new package, please make sure that you have read the package naming guidelines: https://pkgdocs.julialang.org/v1/creating-packages/#Package-naming-guidelines 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] I'm not entirely sure "micropackages" like this are a good idea… but OK. |
Isn't this just |
[noblock] Comparing against 0 requires promotion which is harder to implement than |
[noblock] It does seem like an overkill, but I suppose the package name wouldn't collide with a "more normal" package and hence doesn't occupy the public resource. |
It's just an example, you can do |
[noblock] julia> x=BigFloat(1)
1.0
julia> @btime !(signbit(x) || iszero(x))
65.884 ns (0 allocations: 0 bytes)
true
julia> @btime x>=zero(BigFloat)
97.904 ns (4 allocations: 144 bytes)
true (explaining my second point) Some types support general comparison but there is shortcut when they encode the sign and zero information in their data structures. On your second point, it's not a personal package. It's motivated by a request by someone else from the main Julia repository. |
Your benchmarks are a good case for a PR to the main Julia repository, so that every user of BigFloat can take advantage of this when they use
Oh, I wasn't aware - could you share a link to that conversation? |
I'm assuming the JuliaLang/julia#35067 linked in the README |
“Polluting the namespace” isn’t really what concerns me about micropackages. The problem is the cost of adding a dependency to a project, see, e.g. https://lucumr.pocoo.org/2019/7/29/dependency-scaling/ and the earlier post linked therein. In Julia, the problem is even worse because a project cannot contain multiple versions of the same dependency. Thus, the more dependencies there are, the higher the risk of non-instantiable projects due to dependency conflicts. That’s why we should avoid normalizing micropackages in General. |
Practically, getting a PR to be merged to the Julia base is much harder than package registration. I had a few attempts before but they mostly don't work.
Are there cases when the dependabot can't handle? Micropackages wouldn't have many versions thus the version conflict is less likely. If you had a package which is basically a collection of micropackages, then the frequency of updating it is much higher and thus it's easier to have a version conflict. I think it's also why large projects tend to build on a family of small packages.
It's going off-topic, but the problem is that |
Thanks, I missed that. I don't see anyone asking for this to be a package; the only mention of "General" is the phrase "in general", which is an idiom. In this case, it's referring to having constant propagation working for all types, which is not possible for all
For Julia types that don't have to interface with an external library like GMP (as julia> f(x) = x >= zero(typeof(x))
f (generic function with 2 methods)
julia> g(x) = !(signbit(x) || iszero(x))
g (generic function with 2 methods)
julia> @benchmark g(x) setup=(x=rand())
BenchmarkTools.Trial: 10000 samples with 1000 evaluations.
Range (min … max): 1.889 ns … 9.610 ns ┊ GC (min … max): 0.00% … 0.00%
Time (median): 1.910 ns ┊ GC (median): 0.00%
Time (mean ± σ): 1.915 ns ± 0.144 ns ┊ GC (mean ± σ): 0.00% ± 0.00%
▄ █
▃▁▁▁▁▁▁▁▁▃█▁▁▁▁▁▁▁▃█▁▁▁▁▁▁▁▁▅▁▁▁▁▁▁▁▁▂▃▁▁▁▁▁▁▁▂▃▁▁▁▁▁▁▁▁▂ ▂
1.89 ns Histogram: frequency by time 1.95 ns <
Memory estimate: 0 bytes, allocs estimate: 0.
julia> @benchmark f(x) setup=(x=rand())
BenchmarkTools.Trial: 10000 samples with 1000 evaluations.
Range (min … max): 1.719 ns … 13.040 ns ┊ GC (min … max): 0.00% … 0.00%
Time (median): 1.740 ns ┊ GC (median): 0.00%
Time (mean ± σ): 1.742 ns ± 0.173 ns ┊ GC (mean ± σ): 0.00% ± 0.00%
▆ █
▂▄▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▃▁█▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▃▁█▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▂▄ ▂
1.72 ns Histogram: frequency by time 1.75 ns <
Memory estimate: 0 bytes, allocs estimate: 0. So the "performance problem" seems exclusive to the GMP backed types. Considering that these types are quite often used in calculations that are vastly more complicated and take orders of magnitude longer than 30ns (or 2ns on my machine, as timed by your benchmark above), I don't think this is worth it. |
I just think it would be a bad idea for any package to pull this in as a dependency. I'd definitely flag it in any code review. You could try to get these functions into Or if not in But beyond that, these definitions should be copied into projects instead of loaded from a dependency. So the right approach would be a "blog post" that is easily findable for people googling |
Interestingly Julia has the fallback so if you define a comparison operator, you can also use it. |
JuliaLang/julia#53677 |
Closing at @putianyi889's request. The plan is to pursue JuliaLang/julia#53677 |