ofloveandhate
commented
1 year ago This issue could certainly be solved by using a longer numeric type. That's a fix that would need to be done in Bertini 1, which is not this repository. How about you write an email to Jon Hauenstein and me, and let's talk about making that modification in B1.
But first, note that this is over 4 billion paths ... I'm wary of running such a process.
- Are you prepared to dedicate the computer time?
- Have you estimated the amount of time it will take to complete such a solve? You will certainly need a many-processor computer. I estimate that if each path takes 0.01 seconds to track (🤷♀️), and you use 64 processors, this solve will take 8 days. If it's 0.1 seconds per path (🤷♀️), this is 80 days on 64 processors -- not realistic at all. You only want to do this once, so getting the tracking settings right on the first pass will be important.
- There are likely to be failed paths, too, with that many paths; re-running the failed paths may be tricky. That's out of the scope of this issue.
I also am curious about whether there's a multi-homogeneous start system that might offer lower number of start points. Sadly, there's no automated way to find this out built-in to Bertini 1. (Bertini 1 tells you the number after writing all the start points to an enormous file. Bertini 2 offers some tools for querying the number of start points before / without starting tracking, so this might be an option. Plus, B2 uses better numeric types for numbers of things, so it shouldn't experience this same overflow issue. But, Bertini 2 isn't parallel-enabled at this time, so B2 is not an option for actually doing the solve).
SeffyVon
Hello,
Apologize if this issue of Bertini v1.6 should not be reopened in this way, but I was experiencing the same problem of solving 34 equations and 34 variables. These equations worked fine on 6 equations and 6 variables and they worked perfectly. Here is the same error message.
In Issue #157 it is said that it is due to the variable that stores the number of startpoints being a 32-bit integer, thus allowing only $2^{32}$ startpoints. The suggestion of trying regeneration was way too long, as it iterates $2^1+2^2+...+2^{34}$ paths, and I cannot simplify the equations.
Sorry for my naive assumption about how the code works, but could this limitation be alleviated by using a 64-bit integer? Something like the suggestions in https://stackoverflow.com/questions/9606455/how-to-specify-64-bit-integers-in-c.
I understand that this is an additional development request, but this might potentially scale the calculation capacity up tremendously.
Thank you for your help!