Should there be an OddHalfInt type?

[jishnub]

Such that +(::OddHalfInt, ::OddHalfInt) and -(::OddHalfInt, ::OddHalfInt) would lead to an Int result in either case. Implementation wise, these may wrap HalfInt numbers with an additional check upon construction.

[sostock]

I have thought about adding such a type before, but it hasn’t been a priority for me. Is there a real usecase for it?

I would probably not wrap a HalfInteger type but an Integer type such that reinterpret(OddHalfInt, x) == x + 1//2 (if reinterpret worked on composite types). That way one doesn’t “waste” half of the possible values.

[jishnub]

Yes, that makes sense. One use-case that I can think of is Jacobi polynomials of degree (a,a) are equivalent to an ultraspherical polynomial of order a+1/2. Now, ultraspherical polynomials of integer orders have fast banded conversions from Chebyshev polynomials. With a being an OddHalfInt, we'll know statically that a+1/2 is an integer. Currently, in ApproxFun.jl, this is somewhat hack-y, by checking that a - 0.5 is approximately an integer.

[jishnub]

I've created a package https://github.com/jishnub/OddEvenIntegers.jl to iron out the issues. Since the concept of an odd integer is orthogonal to a half integer, these may exist separately, and be composed to create a half-odd-integer type. I'm closing this issue as there's nothing to be done here.