microsoft
Add BigInt variants of all Int methods
When testing an adder, I noticed that as soon as I went to larger sizes some of the functions I was using did not have BigInt variants.
For example, I needed to write BigInt variants of these three functions:
MeasureInteger
DrawRandomInt
ApplyXorInPlace
(This would all be moot if Q# was big-int-by-default like python!)
@Strilanc Thanks for filing! @cgranade This is something for the libraries API - where do you want to track it and what's the appropriate milestone?
@bettinaheim @Strilanc: Let me go on and move this to the libraries repo as a feature request. From there, the process will be to propose a new API including that enhancement and schedule it for one of the monthly API reviews. Thanks for filing this, @Strilanc!
@msoeken @guenp: Thoughts on including this as part of the changes with https://github.com/microsoft/QuantumLibraries/issues/337?
@cgranade I agree to include BigInt-variants for all Int methods as part of the changes with #337. In general, I think that having Q# bit-int-by-default as mentioned by @Strilanc is an interesting idea.
It sounds like there's alignment, then, that #337 is the right place to act on that feedback. Will revise that proposal to incorporate and schedule discussion for the December API review.
@msoeken, @Strilanc: Would either of you be willing to file BigInt-by-default as a suggestion on qsharp-language? I'm happy to capture that in qsharp-language if not.
@cgranade I am not sure what BigInt by default would mean for Q#? there is no default; we have literals for each data type, and no automatic cast or conversions. Hence the data type is whatever you define it to be when you instantiate the value. This is more of a library ask I believe.
It means the literal 1 is a BigInt instead of an Int. And slices would be over big ints instead of over ints. Almost everything would be big ints. Basically you would be renaming Int to Int64 and BigInt to Int, and Int64 would almost never be used. That's what I mean by big-int by default.
The slices or rather support for BigInt ranges is a good point. The concern from my side would be performance and the amount of work to fully support that throughout all our tools.
There might be some tricks that one can leverage to address performance issues such as a small integer cache as used in Python's C implementation.
Tagging this as a Status-ChildIssue of https://github.com/microsoft/QuantumLibraries/issues/337.
