为何存在mpfr_set_sj_2exp却无mpfr_sub_sj？是否需新增sj/uj变体？

现象说明 #

• mpfr_set_xx_2exp系列包含sj/uj变体：查看mpfr.h头文件可知，该系列函数支持intmax_t（对应sj）和uintmax_t（对应uj）类型：

  $ grep -P 'int mpfr_set_.*_2exp' mpfr.h
  __MPFR_DECLSPEC int mpfr_set_z_2exp (mpfr_ptr, mpz_srcptr, mpfr_exp_t,
  __MPFR_DECLSPEC int mpfr_set_si_2exp (mpfr_ptr, long, mpfr_exp_t, mpfr_rnd_t);
  __MPFR_DECLSPEC int mpfr_set_ui_2exp (mpfr_ptr, unsigned long, mpfr_exp_t,
  __MPFR_DECLSPEC int mpfr_set_sj_2exp (mpfr_ptr, intmax_t, intmax_t,
  __MPFR_DECLSPEC int mpfr_set_uj_2exp (mpfr_ptr, uintmax_t, intmax_t,
  

• mpfr_sub_xx系列无sj/uj变体：同样查看头文件，该系列仅支持unsigned long（ui）、long（si）、GMP大整数（z）等类型，没有对应intmax_t/uintmax_t的变体：

  $ grep -P 'mpfr_sub_' mpfr.h
  __MPFR_DECLSPEC int mpfr_sub_q (mpfr_ptr, mpfr_srcptr, mpq_srcptr, mpfr_rnd_t);
  __MPFR_DECLSPEC int mpfr_sub_ui (mpfr_ptr, mpfr_srcptr, unsigned long,
  __MPFR_DECLSPEC int mpfr_sub_si (mpfr_ptr, mpfr_srcptr, long, mpfr_rnd_t);
  __MPFR_DECLSPEC int mpfr_sub_d (mpfr_ptr, mpfr_srcptr, double, mpfr_rnd_t);
  __MPFR_DECLSPEC int mpfr_sub_z (mpfr_ptr, mpfr_srcptr, mpz_srcptr, mpfr_rnd_t);
  

疑问 #

1. 这种函数支持差异的产生原因是什么？
2. 为mpfr_sub_xx（及其他类似算术运算函数）新增sj/uj变体是否有实用价值？

一、差异产生的原因 #

1. set_xx_2exp的特殊定位：mpfr_set_xx_2exp的核心作用是将整数直接按二进制左移指定指数后写入MPFR变量，这类操作需要直接对接底层整数的二进制表示。intmax_t/uintmax_t是C标准定义的最大宽度原生整数类型，跨平台下能覆盖所有原生整数的取值范围，提供sj/uj变体可以让用户直接传递任意宽度的原生整数，无需手动转换，彻底避免溢出风险。

2. sub_xx系列的兼容性与实现成本考量：

   • 替代方案成熟：MPFR已经提供了mpfr_sub_z支持GMP的大整数类型mpz_t，而intmax_t/uintmax_t可以通过mpz_set_sj/mpz_set_uj快速转换为mpz_t，转换逻辑简单且性能损耗极低。
   • 维护成本较高：若为sub_xx新增sj/uj变体，意味着要为加法、乘法、除法等所有同类算术函数都实现对应的分支，会大幅增加代码量和后续维护负担。
   • 历史迭代差异：MPFR的API是逐步完善的，set_xx_2exp的sj/uj变体可能是后期为了填补跨平台原生整数支持的空白而新增的，而sub_xx系列因为已有足够的替代方案，优先级较低，未进行补充。

二、新增sj/uj变体的实用价值 #

1. 有限的场景价值：

   • 在轻量场景中，若不需要引入GMP大整数库，直接使用sj/uj变体可以减少类型转换的代码，让逻辑更简洁。
   • 极端性能敏感场景下，直接处理intmax_t/uintmax_t可能比转换为mpz_t略快（虽然差异非常微小）。

2. 总体必要性偏低：

   • 现有API已覆盖绝大多数需求：普通整数用si/ui变体，超大整数用mpz_t配合mpfr_sub_z，intmax_t的转换步骤并不繁琐，额外代码量极少。
   • 从项目维护角度看，新增变体带来的收益远低于增加的代码维护成本，且这类需求并不普遍，因此性价比不高。

内容的提问来源于stack exchange，提问作者pmor