search

oscbyspro / Ultimathnum

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

Try compact InfiniInt<T> storage model #7

Closed oscbyspro closed 1 month ago

oscbyspro commented 1 month ago

As noted by the (#3) and (#6) edge cases, I suspect that it might be simpler to store InfiniInt\<T>'s appendix bit as the last bit in its body rather than as a separate extension bit. Maybe it's better, maybe it's worse. In either case, it's something I want to try.

oscbyspro commented 1 month ago

That moment when you rewrite a module in 3 hours and everything just works. Lmao. I'll take a day or two to decide on whether this is the approach I want. It's definitely simpler, that's something at least. I'm not sure how it compares. The fib measurements are unchanged—but they are obviously asymptomatic—and I'm too busy starving to micro-benchmark it.

oscbyspro commented 1 month ago

It appears that this approach is a bit slower on the smaller end, but not that much. I suspect some of this is because of the added element making some (n + m) operations (n + m + 0...2) instead. As an example, UXL(UX.max) has a [~0, 0] body. So it might be worth trimming descending zeros in finite and nonnegative algorithms. Or, I could just keep it simple and let it be.

oscbyspro commented 1 month ago

At the same time, I prefer the current normalization mode. The extra element is weird. I may also want to turn the storage into an enum that fast-paths small values, which would make the extra bit basically free. It also translates directly to the data integer format. Hm.

oscbyspro commented 1 month ago

I chose the zero-dropping solution mentioned in (#6) because I prefer the normalization mode of the extended format.