关于GMP库缺失mpz_tdiv_r_2exp_ui及mpz_tdiv_r_ui设计的技术问询

一、为何缺少unsigned long int mpz_tdiv_r_2exp_ui(const mpz_t n, mp_bitcnt_t b)函数 #

GMP的函数设计遵循一致性与简洁性原则，缺少该函数的合理原因如下：

• 场景需求低且冗余：需要对2的幂取余并直接返回unsigned long int的场景并不普遍，用户完全可以通过现有函数组合实现：先用mpz_tdiv_r_2exp计算余数并存入mpz_t变量，再调用mpz_get_ui提取为unsigned long int。这个组合操作的性能损耗可忽略，单独新增函数会导致API冗余。
• 接口分类逻辑限制：GMP函数命名有明确分类，_ui后缀对应除数为unsigned long int的运算，_2exp后缀对应2的幂位运算。将两者结合的函数会打破现有分类体系，增加API复杂度与维护成本。
• 开发优先级考量：GMP核心团队优先开发高需求、高价值的函数，这类小众组合需求不在优先开发列表中。

二、mpz_tdiv_r_ui的设计逻辑及文档问题 #

设计合理性 #

该函数的设计并非冗余，而是基于以下考量：

• 接口家族一致性：mpz_tdiv_r_ui属于div_ui函数家族，该家族所有函数（如mpz_tdiv_q_ui、mpz_div_ui）都遵循“传入存储结果的mpz_t参数”的约定。统一的接口模式降低了用户学习成本，让系列函数的使用逻辑更连贯。
• 场景灵活性：虽然函数返回unsigned long int类型的余数，但如果用户后续需要对余数进行大整数运算，直接传入mpz_t r就能省去unsigned long int转mpz_t的步骤，反而提升性能。GMP需要兼顾“仅需小整数结果”和“需继续大整数操作”两种场景。
• 历史兼容性：该函数的设计延续了早期GMP的接口风格，为避免破坏大量现有代码的兼容性，即使看起来有冗余，也不会轻易修改参数结构。

文档错误问题 #

你提到的文档描述确实存在错误，mpz_tdiv_r_ui会同时修改传入的mpz_t r并返回余数，文档中“实际上div_ui系列函数仅返回余数”的表述不准确，这属于文档疏漏，你可以提交修正请求。

关于变更请求 #

如果经过评估，你认为上述原因不足以支撑现有设计，完全可以向GMP项目提交变更请求。但需要注意：

• 对于新增mpz_tdiv_r_2exp_ui，需说明该函数的广泛应用场景，证明其实际价值；
• 对于修改mpz_tdiv_r_ui的接口，需考虑是否会导致现有代码兼容问题，以及是否有更优替代方案（比如新增一个无mpz_t r参数的版本）。

内容的提问来源于stack exchange，提问作者Daniel S.