`Uint::wrapping_div_wide(_exact)`

[kayabaNerve]

As we have rem_wide, I'd like to request wrapping_div_wide with a type signature:

fn wrapping_div_wide<const HI_LIMBS: usize, const RHS_LIMBS: usize>((lo, hi): (Self, Uint<HI_LIMBS>), rhs: &NonZero<Uint<RHS_LIMBS>>) -> Self;

(or approximate)

For my specific use case, I know the division to be exact, hence why I'd be fine with a wrapping_div_wide_exact method instead of a wrapping_div_wide method. I did poke at adding this myself but it appeared non-trivial. Modifying div_exact to also intake a x_hi: &mut UintRef, indexing x_lo when xi < x_lo.nlimbs() and x_hi otherwise was fine, but it still poked a bit too much for me to be comfortable without first making an issue to discuss this.

My practical use-case is I have such a need within my code and currently do lo.concat(hi).div_exact(rhs), but this requires the types implement Concat. As my segments are ~5k bits, the only types which reliably implement Concat are U6144, U8192, at which point I'm way over the size I'd like to be operating with. Removing the Concat bound would dramatically increase which types are eligible for use within my constraints.

This is horribly niche and I would not be offended at all if this was immediately closed as out-of-current-scope-availability/unreasonable.

[andrewwhitehead]

I could see adding a wide version of div_exact I think, the crate private implementation could probably have an optional high UintRef without affecting performance. In recent versions you can also use Uint::concat_checked which doesn't have the Concat trait bound.

[kayabaNerve]

Yes, I did sketch accepting a hi and it seemed fine, just not something I wanted to submit a PR for without prior dicussion :)

concat_checked does seem like a decent solution to some of the problems with Concat, but with the obvious trade-off it removes the bound for explicit specification of the associated type. This somewhat returns to discussing a Ctx generic (#1314). Thanks for pointing it out :)