MeasureTheory.jl currently has InfiniteArrays.jl as a dependency, because @dlfivefifty has some nice utilities for dealing with infinity as an integer value. This makes it handy for representing things like the support of a Poisson measure (we can write ℤ[0:∞]). Here’s the code we depend on.
The obvious solution is to have an Infinity.jl the “owns” the name and has some sensible properties, and have everything depend on that. But there’s already such a library! Here’s Infinity.jl from @cjdoris .
But that doesn’t quite solve it, because here the standard is ∞ <: Real.
So, my hope is that there might be a way to include all of the “infinity functionality” in Infinity.jl. Then everything that needs ∞ can depend on this one package.
So InfiniteArrays.Infinity becomes Infinities.InfiniteCardinality and ∞ becomes more of a catch-all.
Actually this is mostly completed and just needs to be tagged and tested. I can do this shortly to start the process. If you have any opinions on the design please file issues
Thanks @dlfivefifty for the quick response. Looks like you’re way ahead of me
Thanks. Right now my biggest concern is with ongoing collisions between Infinity.jl and Infinities.jl. I can just choose one, but others might choose a different one, and suddenly our packages don’t work well together. Do you see any fundamental incompatibilities with Infinity.jl? Packages like this are relatively small, but small packages with commonly-needed concepts can end up with hundreds of dependencies over time.
Do these packages have any big differences in their goals or technical approach?
I designed Infinities.jl in conjunction with the creator of Infinity.jl as a complete replacement, so someone just needs to add the remaining features from Infinity.jl to Infinities.jl and change the dependencies.
In the meantime, just use import instead of using to avoid clashes
Hi, author of Infinity.jl here. Yes, use Infinities.jl instead.
I’ve been too distracted lately by other projects, but I’ll try to make some time to port all the functionality over soon. Contributors from packages dependent on mine have very kindly ensured it has 100% test coverage, so I’d like to replicate that here.
Infinities.RealInfinity would allow me to replace ∞ in TransformVariables, but I don’t quite see the point of Infinities.Infinity — I would just treat it as a special case of Infinities.RealInfinity, and use ∞.
This has the advantage of -∞ not changing type. Should I open an issue about this?
It is not clear to me from the project plan why Infinities.Infinity is replacing Infinity.Infinity, not RealInfinity(true).
That said, what I really need for TransformVariables is a distinct positive and negative “infinity” type, ideally available with ∞ and -∞, that I can dispatch on so that TransformVariables.as is type stable.
Please file an issue if you want to discuss further. I believe @cjdoris had a need for a positive real infinity called ∞. I personally only need InfiniteCardinal and so would be OK with const ∞ = RealInfinity().
+1
Many have needed a positively signed infinity and a negatively signed infinity that were distinctly subtyped from shared abstraction. I am opening an issue at Infinities.jl, please contribute your perspective.
and have now registered the package. So v0.0.1 will be available in 3 days