Our use of BigInt internally is the cause of some slowness, and I've shown in #135 (comment) that by replacing it we can get immediate efficiency improvements. This however can't be done naively, so we'll need to consider how we support generation of uint64, int64, double, and bigint with a different internal type.
Something we may want to consider is grouping numeric types into a few categories:
- Signed integers (
int8, int16, int32, int64)
- Unsigned integers (
uint8, uint16, uint32, uint64)
- Floating point numbers (
single, double)
Then we can have one integral function for each category that uses the largest number in its category to generate from. This would help us avoid weird conversion issues and allow us to drop BigInt internally.
I do, however, think we should add a Gen.bigint function. But that is outside the scope of this issue, and should be considered on its own merit.
Thoughts?
/cc @TysonMN @dharmaturtle @moodmosaic
Our use of
BigIntinternally is the cause of some slowness, and I've shown in #135 (comment) that by replacing it we can get immediate efficiency improvements. This however can't be done naively, so we'll need to consider how we support generation ofuint64,int64,double, andbigintwith a different internal type.Something we may want to consider is grouping numeric types into a few categories:
int8,int16,int32,int64)uint8,uint16,uint32,uint64)single,double)Then we can have one
integralfunction for each category that uses the largest number in its category to generate from. This would help us avoid weird conversion issues and allow us to dropBigIntinternally.I do, however, think we should add a
Gen.bigintfunction. But that is outside the scope of this issue, and should be considered on its own merit.Thoughts?
/cc @TysonMN @dharmaturtle @moodmosaic