Yuto Horikawa

>What was wrong with just using `1..Inf` ? * It promotes `Int` to `Float64`, so it's better to have a method to avoid the promotion. (x-ref: https://github.com/JuliaMath/IntervalSets.jl/issues/115#issuecomment-1219874621) * Non-real intervals...

The topics in this issue and #122(#121) are totally different. We just want unbounded intervals, and non-promoted `1..Inf` is incomplete because it's different from `1..Inf32`. (We don't want to distinguish...

It's okay to have `1..Inf32 == 1..Inf` because `Inf32 == Inf`. What I mean was, defining unbounded intervals should not depend on whether `Inf::Float64` or `Inf32::Float32`.

The subtypes of `IntervalSets.TypedEndpointsInterval` have information about whether the endpoints are closed in their type. However, `AbstractInterval` does not require the property, so if someone wants a type-stable interval type...

The dependency on `EllipsisNotation` was removed, so I will reopen this issue. https://github.com/JuliaMath/IntervalSets.jl/pull/83

I think it would be nice to have a lightweight package `DotDots.jl` which defines `DotDot` struct. ```julia struct DotDot

I still think the `eltype(::Interval)` method should be removed. Because the use of `Base.eltype` is intended for iterable objects (see [documentation](https://docs.julialang.org/en/v1/base/collections/#Base.eltype)), and the method `eltype(::Interval)` can be considered as *"Type...

Maybe, it seems better to add the `domain` method to `ApproxFunBase.domain`. https://juliaapproximation.github.io/ApproxFun.jl/latest/library/#ApproxFunBase.domain

Hi! Thank you for this great package! I'm also developing another package for B-spline: [BasicBSpline.jl](https://github.com/hyrodium/BasicBSpline.jl). With this package, some of the roadmap seem solved. >Allow knot vectors where the first...

Thanks for the response! >I started to implement arbitrary knot vectors in #5, but that was already a long time ago. I don’t have the time to finish it right...