OverflowContexts.jl

[BioTurboNick]

Thought I would formally link to my variant in this area, OverflowContexts.jl, in part to explore if they could/should be merged.

[kimikage]

When I made CheckedArithmeticCore(#6, #8), CheckedArithmetic.jl was the only package that "practically worked" with respect to overflow issue.

Aside from the fact that OverflowContexts.jl is superior in terms of functionality, I am interested in the package name.

#9 (comment)

As mentioned in https://discourse.julialang.org/t/rfc-what-should-the-arithmetic-within-the-fixedpointnumbers-be/46697, I would like to add the definitions of arithmetic operations such as saturating_add and wrapping_sub, currently defined in FixedPointNumbers#master, to the CheckedArithmeticCore.

They are "unchecked", so it is a self-contradiction that they join the CheckedArithmetic. 😅 However, I think it's reasonable to assume that they just provide the opt-out functionality.

In other words, if saturating arithmetic is to be supported, I think OverflowContexts (or its derivatives) is more appropriate, at least in terms of name.

This is partly my fault, but this package has not changed practically for a long time.
@timholy, what do you think about making OverflowContexts.jl the successor to this package?

[kimikage]

@BioTurboNick Is OverflowContexts.jl compatible with julia v1.0?
Since v1.0 is old, I don't see the need for the additional support, but if it actually works, supporting v1.0 might make the migration smoother.

[kimikage]

xref: https://discourse.julialang.org/t/revisiting-saturating-intrinsics/112917/

[BioTurboNick]

It seems OverflowContexts.jl is only partly compatible with 1.0, I'll take a closer look to see if it's easily addressable, see no reason not to try.

[BioTurboNick]

Good news, it appears to be compatible after all. Just forced me to confront some bugs and deal with a change in 1.11.

[kimikage]

I am not a member of JuliaMath, so I cannot transfer OverflowContexts.jl to the organization. (It is, of course, reasonable to maintain it as a personal repository.)
And @timholy is always busy.

[StefanKarpinski]

We can add you and let you keep maintaining it here. If you ping me on Monday I'll do it.

[kimikage]

@StefanKarpinski
Let me make sure there is no misunderstanding.
By "you" do you mean me (@kimikage)? Or you guys, i.e. @BioTurboNick too?
By “here” do you mean “JuliaMath”?

If a member of JuliaMath transfers the repository via the member, at least I don't have to join JuliaMath.

Also, this seems like something that should be reviewed by @timholy once.
As you know, he is the creator of CheckedArithmetic.jl and has given good thought to the overflow issue (cf. https://discourse.julialang.org/t/rfc-what-should-the-arithmetic-within-the-fixedpointnumbers-be/46697/6).
At least he will reply within 3 years, unlike me. 😄

[BioTurboNick]

This works for me, happy to contribute it to the org and also to keep maintaining it.

[StefanKarpinski]

Ok, who should I add to the JuliaMath org? @BioTurboNick and @kimikage? Or just @BioTurboNick?

[kimikage]

One "authorized" person should be enough for this matter (i.e., the repository transfer).
I'd be happy to have more contributors, though.

[StefanKarpinski]

I've invited you both to JuliaMath.

[timholy]

I don't have a deep attachment to this package. If OverflowContexts.jl is superior---and it looks to be---I'd strongly support having other packages migrate to using it.

One missing element might be https://github.com/JuliaMath/CheckedArithmetic.jl?tab=readme-ov-file#accumulatortype-and-acc. The basic idea is that in addition to detecting/handling overflow, packages should also be able to recommend ways to avoid it. Generic algorithms leverage that info.

[kimikage]

As for accumulatortype, 4 years ago I expressed my concerns.
JuliaMath/FixedPointNumbers.jl#146

I don't think something like accumulatortype is unnecessary, but we could offer something more safer and faster (with SIMD).

So, I am not going to force users who are already using accumulatortype to migrate to OverflowContexts.jl.

Seeing that packages which provide numeric types, including FixedPointNumbers.jl, do not implement accumulatortype, it seems to me that it would be better to create a separate package (like SafeAccumulation.jl or something). Unlike 4 years ago, we now have the package extension mechanism.