Hi Robert! On Nov 26, 9:46 am, Robert Bradshaw <rober...@math.washington.edu> wrote: [...] > >> I think this makes perfect sense...I'm actually surprised it's not > >> implemented that way already. > > > That's impossible. > > Over-allocating the number of generators ahead of time whenever you > need more to achieve O(log(n)) rather than O(n) ring enlargements for > n used variables (where n is, of course, not know ahead of time) seems > easy enough to me.
Over-allocation could indeed be a good idea. By "impossible" I meant: When you have sum([x[i] for i in range(1001)] it is impossible to guess that eventually you will have 1000 variables already at the time when you create x[0]. And when you create x[1000] first, then you have two approaches: 1) I don't know whether any other variable will be used, thus, I only create x[1000] and nothing else. That's the sparse implementation. 2) If x[1000] is used, it is likely that x[999] will be used as well. So, I create x[0],...,x[1000] at once. That's the dense implementation. [...] > > Or start summation with the highest index, which has the same effect. > > Or use *symbolic* variables right away, since this is what Nathann > > needed anyway. > > I'm clearly not following you--I thought the point was that one didn't > know ahead of time the highest index. Yes. InfinitePolynomialRing can not know the highest index. But if the user happens to know the highest index, (s)he can forward this information to InfinitePolynomialRing, by using the highest index first (in the default implementation). Once more: I think the crucial point is whether in a given application the number of variables can grow by arithmetic operations. For InfinitePolynomialRing, the action of an infinite symmetric group can obviously raise the variable index beyond all bounds. And this is what can happen during symmetric Groebner basis computation. If in Nathann's application there is no such group action (and no shift operator) then he might be better off using symbolic variables right away. Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
