∞ name collision

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.

But this has some issues,

  • We’re bringing in a lot of other code from InfiniteArrays we’re not currently using, and
  • The name collides with an export from @Tamas_Papp 's TransformVariables.jl, which we also rely on heavily.

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.

Do you think this can work out?

3 Likes

The plan is to combine the two approaches in

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

6 Likes

Thanks @dlfivefifty for the quick response. Looks like you’re way ahead of me :slight_smile:

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

2 Likes

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.

4 Likes

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?

No this was thought through and discussed, see project plan, there’s a need for positive infinity.

I got inspired and got the codecov to :100: and have now registered the package. So v0.0.1 will be available in 3 days

3 Likes

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 Like

+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.

Thanks, done.

It’s exciting to see this moving forward! Thanks all.

3 Likes

open for comment

1 Like