oscbyspro / Ultimathnum

Binary arithmetic reimagined in Swift
Apache License 2.0
9 stars 1 forks source link

Ban infinite dividends #69

Closed oscbyspro closed 1 week ago

oscbyspro commented 2 months ago

Banning infinite dividends seems like the simplest solution to (#68). It would also mean that all safe division inputs are well-behaved. Infinite dividends would be banned by setting the type to Finite\<T>. Imagine the following with some conveniences:

protocol BinaryInteger {
    static func division(_ dividend: Finite<Self>, by divisor: Nonzero<Self>) -> Fallible<Division<Self, Self>>
}
oscbyspro commented 2 months ago

Infinite-by-infinite division is well-behaved but also uninteresting; it's a conditional subtraction. I could add nicher constraints than Finite\ and Natural\ but I prefer to keep it simple :tm: to the extent that it is possible.

oscbyspro commented 2 weeks ago

I've prototyped a new approach using (#95). It seems a bit annoying to maintain, but otherwise viable. I could, perhaps, reduce it to just Optional<T> since the there's only one finite error case, T.isSigned && a == T.min && b == -1. I'm not yet convinced that taking such shortcuts is a good idea, however.

oscbyspro commented 2 weeks ago

I've had other ideas too. Like, I could strengthen the input guarantee such that only well-behaved divisions are allowed, basically hoisting all preconditions. That might be convoluted in another way, but I don't want to dismiss the idea just yet.

oscbyspro commented 2 weeks ago

I basically want the Fallible<T> part because of invariants like this:

I8(-128).quotient(Nonzero(-1)) == I8.exactly(IXL(-128) / IXL(-1))

Division is just a weird operation where almost all inputs are valid. Sigh.

oscbyspro commented 2 weeks ago

Back to the original post: divisions of infinite dividends are useless; a blanket ban is a viable alternative.

oscbyspro commented 1 week ago

I'll resolve this issue by tomorrow. The combinatorial maintenance hazard of implicit error propagation was the biggest blocker and it was resolves by moving on to the new sink approach (#116) (#117).