?Return type of primorial (similar to factorial) applied to Int?

[JohnAAbbott]

primorial(n) returns the product of all primes up to n (incl.). The on-line manual reports that it accepts Int and ZZRingElem are argument types. When called with a "large" Int value, it computes the answer, and then triggers an error when trying to convert the answer to Int. Why does it want to convert the answer to Int?

The Julia function factorial also "overflows" if the given argument is a "large" Int (on my computer "large" means greater than 20). Personally I find this restriction quite unnatural, but the design is imposed on us by Julia. Do we really want to mimic this restriction for the function primorial? Why?

In case anyone is interested: primorial gives error on my computer if the argument is Int greater than 52. If we do preserve this behaviour then this should be made clear in the documentation.

[JohnAAbbott]

No replies after 3 weeks? Perhaps we were all busy with other more pressing matters.
One possible (but rather weak) argument in favour of mimicking the behaviour of the Julia function factorial is that the user does not need to memorize which functions behave which way: e.g. if one is used to primorial always returning a ZZRingElem then it could be jarring to discover that factorial does not also do so.

[fieker]

Mostly, "all" functions taking Int as input produce Int as output. Mostly that makes sense, but not everywhere. IN particular, here the error should be BEFORE any computation happens...

[JohnAAbbott]

?primorial produces two identical manual entries: one for Int and one for ZZRingElem. It would be nice to condense them into a single entry with both signatures... any objections to this?

[JohnAAbbott]

I can add some simple arg checks. It is a little odd that InexactError wants to report also the unconvertable value.
Note to self: must handle 3 cases: Int32, Int64 and Int128

[thofma]

Should be fixed