complexity of `orbits` and hence `toricBlowup` is exponential for blowing up at a point

[mahrud]

I noticed that toricBlowup for a point in PP^n seems to grow exponentially: ~1s, ~3s, ~10s, ~60s for n=14,15,16,17. Try this with:

n = 17; elapsedTime toricBlowup(toList(0..n-1), toricProjectiveSpace n)

The main bottleneck seems to be computation of the orbits.

I haven't read the implementation carefully, but even if the implemented algorithm is optimal for the general case, there are a few potential improvements here for a student or workshop:

1. Both toricBlowup and orbits could be improved using mutable lists and hash tables.
2. Blowups at points should be trivial to compute using a simpler algorithm.
3. The basis for the Picard group chosen for these special blowups could also be chosen better. In Small changes to Varieties and NormalToricVarieties #4014 I added a WeilToClass option to specify my own degree map, but ideally this should be automatic.

cc: @ggsmith

[mahrud]

Actually, when blowing up a point on any toric variety, the clStar list computed here:

M2/M2/Macaulay2/packages/NormalToricVarieties/ToricVarieties.m2

Lines 683 to 688 in 562aea5

	clStar := {};
	for t in star do (
	c := 1 + d - rank rayMatrix_t;
	clStar = clStar | select (orbits(X,c), r -> all (r, j -> member(j,t)))
	);
	clStar = unique clStar;

Could simply be clStar := subsets(s, d-1). Isn't this right @ggsmith?

[ggsmith]

Generally, clStar := subsets(s, d-1) is not correct. This would be correct if one new a priori that cone containing the relevant ray was simplicial.

[mahrud]

Ah yes, I definitely need simplicial for my application so I assumed that. If it's not simplicial, clStar is still a subset of subsets(s, d-1), so probably generating all the subsets then selecting valid cones among them would still be faster.