Hi Hannes,
hannes wrote:
vectors of bintint are already there:
Code:
bigintmat m[1][3]=1,2,3;
I see. The syntax is different than for a vector, so, it isn't truly a vector of bigints, but at least it would be a work around.
Quote:
Using bigintmat as return type of hilb does not help;
the overflow occurs during the computation of the Hilbert function,
Sure.
Quote:
changing that requires a complete rewrite of the code,
if you volonteer for that you are welcome.
Seriously? Of course I don't know the code yet, but I'd be very surprised if the changes go beyond changing data types (internally of course, not just the return type) by search-and-replace.
Quote:
Changing int to long on 64bit machines is a bad idea:
- it does not help the overflow problem (see above)
- 32bit and 64bit version should behave the same way
If I understand correctly, 32bit machines became rare, and so there is some point in arguing that using the capabilities of a 64bit machine should be standard. And even 32bit machines can emulate 64bit ints. It would of course be slower than on a 64bit machine, but it would be the lesser of two evils, IMHO.
I believe that a CAS shouldn't impose an artificial restriction that is motivated by outdated hardware and makes it fail in real-world-applications (by which I mean rings that arise in the study of modular group cohomology). I do no volunteer to change Singular so that "int" means "64bit integers" and "bigint" means "arbitrary size integers", but I think sooner or later it would be needed.
Best regards,
Simon