Open lydia-duncan opened 3 years ago
I don't feel strongly about this. It wouldn't bother me if they were in a submodule, but it definitely doesn't bother me that they're in BigInteger (and leaving them where they are is strictly less work for us and for users in that nothing needs to be updated).
An argument that I put in the meta issue but didn't move over here is: if I was looking for these functions, I'm not sure I would look for them here. Maybe if I specifically wanted bigint
versions of them. I also might not think of them by looking at the module name and could be surprised by them being in my namespace if I used the module without limitation (though really should limit to just the symbols I want).
Having them in a submodule would make it more obvious they exist, and make it easier to find them if I went looking for them.
In a recent discussion (Cray/chapel-private#4969), we decided to mark the following functions unstable pending a later decision on adding a submodule for these.
nextprime
lucnum
/lucnum2
jacobi
/legendre
/kronecker
gcd
/lcm
/fac
/bin
/fib
/fib2
/probablyPrime
Since we've marked them unstable, I'm removing the 2.0 label from this issue
jacobi
,legendre
,kronecker
,bigint.lucnum()
andbigint.lucnum2()
are all algorithms involvingbigint
rather than basic operations on the type. These seem sufficiently different from the majority of the module to perhaps warrant putting them in a submodule focused around computations involvingbigint
s.The latter two are defined as methods on the type but I don't think that's an important distinction (though it would probably be good to unify them - I think it has to do with whether the return value is a
bigint
or a smaller number)If we do move them to a submodule, should gcd, lcm, fac, bin, and fib go with them? (Again, even though they are methods?) At least gcd and lcm feel more "mathy", though they're still arguably algorithms rather than basic computations.