17699, "lydia-duncan", "[Library Stabilization] BigInteger methods overwrite their receiver rather than returning", "2021-05-12T21:00:24Z"
opened 09:00PM - 12 May 21 UTC
closed 03:24PM - 29 Mar 23 UTC
area: Libraries / Modules
type: Performance
type: Unimplemented Feature
type: Chapel 2.0
The documentation indicates that this is better for performance. Should we prov… ide standalone versions that return a new `bigint` instead/in addition? Note that a lot of methods like this create a local copy of their arguments when the arguments are remote (and usually there are two arguments). Should we rename them? Should we add compiler support for translating less optimal (but more understandable) forms into optimal forms? I personally find it a bit odd, though I understand the reason behind it.
Michael says:
> I think it'd be reasonable to consider naming things like proc bigint.add differently [to make it clear that these overwrite their arguments]. But I don't know what we would name them to that would 1) be clear to newcomers and 2) be something one could easily map to a GMP operation.
Nikhil also brought this issue up at https://github.com/chapel-lang/chapel/issues/17616#issuecomment-834053841 and there was some good discussion in https://github.com/chapel-lang/chapel/issues/17616#issuecomment-834247288, https://github.com/chapel-lang/chapel/issues/17616#issuecomment-834544569, and https://github.com/chapel-lang/chapel/issues/17616#issuecomment-834622585
Affected methods are:
- `bigint.divexact()`
- `bigint.powm()`
- `bigint.pow()`
- `bigint.rootrem()`
- `bigint.sqrt()`
- `bigint.sqrtrem()`
- `bigint.nextprime()`
- `bigint.gcd()`
- `bigint.lcm()`
- `bigint.remove()`
- `bigint.gcdext()`
- `bigint.invert()`
- `bigint.fac()`
- `bigint.bin()`
- `bigint.fib()`
- `bigint.fib2()`
- `bigint.lucnum()`
- `bigint.lucnum2()`
- `bigint.add()`
- `bigint.sub()`
- `bigint.mul()`
- `bigint.addmul()`
- `bigint.submul()`
- `bigint.mul_2exp()`
- `bigint.neg()`
- `bigint.abs()`
- `bigint.div_q()`
- `bigint.div_r()`
- `bigint.div_qr()`
- `bigint.div_q_2exp()`
- `bigint.div_r_2exp()`
- `bigint.and()`
- `bigint.ior()`
- `bigint.xor()`
- `bigint.com()`
The documentation indicates that this is better for performance. Should we provide standalone versions that return a new bigint
instead/in addition? Note that a lot of methods like this create a local copy of their arguments when the arguments are remote (and usually there are two arguments). Should we rename them? Should we add compiler support for translating less optimal (but more understandable) forms into optimal forms? I personally find it a bit odd, though I understand the reason behind it.
Michael says:
I think it'd be reasonable to consider naming things like proc bigint.add differently [to make it clear that these overwrite their arguments]. But I don't know what we would name them to that would 1) be clear to newcomers and 2) be something one could easily map to a GMP operation.
Nikhil also brought this issue up at [Library Stabilization] BigInteger module status · Issue #17616 · chapel-lang/chapel · GitHub and there was some good discussion in [Library Stabilization] BigInteger module status · Issue #17616 · chapel-lang/chapel · GitHub , [Library Stabilization] BigInteger module status · Issue #17616 · chapel-lang/chapel · GitHub , and [Library Stabilization] BigInteger module status · Issue #17616 · chapel-lang/chapel · GitHub
Affected methods are:
bigint.divexact()
bigint.powm()
bigint.pow()
bigint.rootrem()
bigint.sqrt()
bigint.sqrtrem()
bigint.nextprime()
bigint.gcd()
bigint.lcm()
bigint.remove()
bigint.gcdext()
bigint.invert()
bigint.fac()
bigint.bin()
bigint.fib()
bigint.fib2()
bigint.lucnum()
bigint.lucnum2()
bigint.add()
bigint.sub()
bigint.mul()
bigint.addmul()
bigint.submul()
bigint.mul_2exp()
bigint.neg()
bigint.abs()
bigint.div_q()
bigint.div_r()
bigint.div_qr()
bigint.div_q_2exp()
bigint.div_r_2exp()
bigint.and()
bigint.ior()
bigint.xor()
bigint.com()