Back to Forum | View unanswered posts | View active topics
Topic review - Feature request: Bigint vectors for Hilbert series |
Author |
Message |
|
|
Post subject: |
Feature request Bigint vectors for Hilbert series |
|
|
for what its worth I built this and have it working for me.
for what its worth I built this and have it working for me.
|
|
|
|
Posted: Mon Dec 03, 2018 10:20 pm |
|
|
|
|
|
Post subject: |
Re: Feature request: Bigint vectors for Hilbert series |
|
|
Dima Pasechnik's account is currently inactive. Therefore he asked me to link this thread to the corresponding github issue: https://github.com/Singular/Sources/issues/881.
Dima Pasechnik's account is currently inactive. Therefore he asked me to link this thread to the corresponding github issue: [url]https://github.com/Singular/Sources/issues/881[/url].
|
|
|
|
Posted: Thu Sep 06, 2018 9:38 am |
|
|
|
|
|
Post subject: |
Re: Feature request: Bigint vectors for Hilbert series |
|
|
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
Hi Hannes,
[quote="hannes"]vectors of bintint are already there: [code]bigintmat m[1][3]=1,2,3; [/code] [/quote] 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, [/quote] Sure. [quote] changing that requires a complete rewrite of the code, if you volonteer for that you are welcome. [/quote] 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[/quote]
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
|
|
|
|
Posted: Tue Sep 04, 2018 10:49 am |
|
|
|
|
|
Post subject: |
Re: Feature request: Bigint vectors for Hilbert series |
|
|
vectors of bintint are already there: Code: bigintmat m[1][3]=1,2,3;
Using bigintmat as return type of hilb does not help; the overflow occurs during the computation of the Hilbert function, changing that requires a complete rewrite of the code, if you volonteer for that you are welcome. 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
vectors of bintint are already there: [code]bigintmat m[1][3]=1,2,3; [/code]
Using bigintmat as return type of hilb does not help; the overflow occurs during the computation of the Hilbert function, changing that requires a complete rewrite of the code, if you volonteer for that you are welcome.
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
|
|
|
|
Posted: Mon Sep 03, 2018 2:00 pm |
|
|
|
|
|
Post subject: |
Feature request: Bigint vectors for Hilbert series |
|
|
Hi!
Since the following was buried in a different larger topic, I create a new small one.
There is int and there is intvec. There is bigint, but there is no bigintvec.
- Would you consider to implement vectors of big integers in Singular? - And would you consider to use bigint vectors or another suitable data type as return value for the hilb function? In my applications, I have rings with many variables (>70), which currently makes hilb(id,1) fail with an int overflow.
Best regards, Simon
Hi!
Since the following was buried in a different larger topic, I create a new small one.
There is int and there is intvec. There is bigint, but there is no bigintvec.
- Would you consider to implement vectors of big integers in Singular? - And would you consider to use bigint vectors [i][b]or another suitable data type[/b][/i] as return value for the hilb function? In my applications, I have rings with many variables (>70), which currently makes hilb(id,1) fail with an int overflow.
Best regards, Simon
|
|
|
|
Posted: Sun Sep 02, 2018 2:12 pm |
|
|
|
|
|
It is currently Fri May 13, 2022 10:56 am
|
|