On Thu, Nov 26, 2009 at 01:42:35PM -0800, Nick Alexander wrote:
> Two things, mostly. The huge amount of code that wasn't being
> merged -- that appears to now be merged :)
For a good part, that was just an instance of a general issue with
Sage's slow review process (and I don't have good suggest
> > Could you elaborate ? What's makes you skeptical ?
>
> Two things, mostly. The huge amount of code that wasn't being merged
> -- that appears to now be merged :) And the whole categories/generic
> code effort: while I support the ends, I'm worried that the system
> will become so slow
On 26-Nov-09, at 12:23 PM, Florent Hivert wrote:
>>> On Thu, Nov 26, 2009 at 08:30:53AM -0800, YannLC wrote:
Just a toy implementation as a very thin layer over dict (at
least it
should be fast)
>>>
>>> That's precisely what CombinatorialFreeModule elements are :-)
>>>
>>> Furthe
> > On Thu, Nov 26, 2009 at 08:30:53AM -0800, YannLC wrote:
> >> Just a toy implementation as a very thin layer over dict (at least it
> >> should be fast)
> >
> > That's precisely what CombinatorialFreeModule elements are :-)
> >
> > Further optimizations to it are most welcome (For example, I am
On 26-Nov-09, at 10:18 AM, Nicolas M. Thiery wrote:
> On Thu, Nov 26, 2009 at 08:30:53AM -0800, YannLC wrote:
>> Just a toy implementation as a very thin layer over dict (at least it
>> should be fast)
>
> That's precisely what CombinatorialFreeModule elements are :-)
>
> Further optimizations to
On Nov 26, 9:31 am, Simon King wrote:
> InfinitePolynomialRing has an underlying *finite* polynomial ring,
> that changes whenever you need a variable that is not in the finite
> ring.
Hi, I have seen this thread has various aspects and I don't know the
details, but just reading this it reminds m
On Thu, Nov 26, 2009 at 05:09:13PM +0100, Florent hivert wrote:
> > On Thu, Nov 26, 2009 at 06:54:43AM -0800, Nathann Cohen wrote:
> > > Actually, I use these polynomials to emulate what your
> > > CombinatorialFreeModule does on a much larger basis : everything that
> > > is hashable ;-)
> > >
>
On Thu, Nov 26, 2009 at 08:30:53AM -0800, YannLC wrote:
> Just a toy implementation as a very thin layer over dict (at least it
> should be fast)
That's precisely what CombinatorialFreeModule elements are :-)
Further optimizations to it are most welcome (For example, I am not
sure += is implement
Just a toy implementation as a very thin layer over dict (at least it
should be fast)
no doc
-
first see it in action:
sage: x=Test()
sage: p=x.zero_element()
sage: time for i in range(1): p+=x[i]
CPU times: user 0
> On Thu, Nov 26, 2009 at 06:54:43AM -0800, Nathann Cohen wrote:
> > Actually, I use these polynomials to emulate what your
> > CombinatorialFreeModule does on a much larger basis : everything that
> > is hashable ;-)
> >
> > I want to be able to index my variables with sets, with edges, with
> >
On Thu, Nov 26, 2009 at 06:54:43AM -0800, Nathann Cohen wrote:
> Actually, I use these polynomials to emulate what your
> CombinatorialFreeModule does on a much larger basis : everything that
> is hashable ;-)
>
> I want to be able to index my variables with sets, with edges, with
> nodes, with al
Actually, I use these polynomials to emulate what your
CombinatorialFreeModule does on a much larger basis : everything that
is hashable ;-)
I want to be able to index my variables with sets, with edges, with
nodes, with almost anything we can come up with in Sage...
Nathann
On Nov 26, 3:39 pm,
On Thu, Nov 26, 2009 at 05:29:47AM -0800, YannLC wrote:
> If you only want linear terms, you can also use an univariate
> polynomial ring
>
> just treat x^i as x_i.
>
> it's lightning fast and allow you to easily access coefficients.
Variant:
sage: F =CombinatorialFreeModule(QQ, NonNegativeInte
Then I think you found the very thing I needed... Thank you !!! :-)
I do not need 1 millions variables, but clearly I do not want the
computations to be too slow under 1.. If I have something like
1000 variables, I very often have 5000 or more functions to define and
work on, so I need the sym
On Nov 26, 2:17 pm, Simon King wrote:
[...]
> However, if I understood correctly, you have a *uni*variate polynomial
> ring, right? So, probably you can disregard what I just said, since
> univariate polynomial rings are different from multivariate (based on
> ntl? not sure...) .
Yep, as pointed
Hi Nathann!
On Nov 26, 2:06 pm, Nathann Cohen wrote:
> I could cache the results... But I still do not understand why just
> evaluating x^99 takes so much time !
I guess this is a limitation of Singular.
In Singular, exponents are restricted to 32767. Usually, multivariate
polynomial rings
because you use dense representation.
Try P.=PolynomialRing(QQ,sparse=True)
By the way, do you need QQ? RR or ZZ would probably be faster.
On Nov 26, 3:06 pm, Nathann Cohen wrote:
> I could cache the results... But I still do not understand why just
> evaluating x^99 takes so much time !
Y
I could cache the results... But I still do not understand why just
evaluating x^99 takes so much time !
On Nov 26, 2:54 pm, YannLC wrote:
> can you avoid sums for initialisation?
>
> sage: P.=PolynomialRing(QQ)
> sage: time p=P(dict([(i,1) for i in range()]))
> CPU times: user 0.07 s, sy
can you avoid sums for initialisation?
sage: P.=PolynomialRing(QQ)
sage: time p=P(dict([(i,1) for i in range()]))
CPU times: user 0.07 s, sys: 0.00 s, total: 0.07 s
Wall time: 0.07 s
On Nov 26, 2:43 pm, Nathann Cohen wrote:
> R = PolynomialRing(QQ, 'x')
> x = R.gen()
> sum([x^i for i in rang
R = PolynomialRing(QQ, 'x')
x = R.gen()
sum([x^i for i in range(2,)])
This is still very slow ( even if the values are larger ) :-/
Nathann
--
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...@googleg
Oops, I misread your message... You're right !! ;-)
--
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:
My problem is that I am dealing with linear functions having an
arbitrary large number of variables.
Nathann
--
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 th
If you only want linear terms, you can also use an univariate
polynomial ring
just treat x^i as x_i.
it's lightning fast and allow you to easily access coefficients.
On Nov 26, 2:10 pm, Nathann Cohen wrote:
> Hello !!!
>
> I am writing the patch to move from InfinitePolynomialRing to just "var
Hello !!!
I am writing the patch to move from InfinitePolynomialRing to just "var
()", and I am having several annoying problems :
To obtain the coefficients of each variable, I have to write
for v in expression.variables():
c = expression.coefficient(v)
And I wonder if this is not a quadrat
On Thu, 26 Nov 2009 02:51:17 -0800 (PST)
Nathann Cohen wrote:
> Hmm After thinking about it for a bit, is using var() really a
> good solution ? It is fast and everything, but I use my variables in
> functions that should not spoil the userspace with them ! When I
> define symbolic variab
Hi Martin!
As you have pointed out in the wrong thread, having a smaller ring
*has* advantages.
But the more I think about it, the more I find it stupid that I let
any element of an infinite polynomial "sparse" ring have its own
underlying finite polynomial ring. It should be better to have the
f
Hmm After thinking about it for a bit, is using var() really a
good solution ? It is fast and everything, but I use my variables in
functions that should not spoil the userspace with them ! When I
define symbolic variables, they are global and could even be accessed
in the userspace... Can
Hi Robert!
On Nov 26, 10:20 am, Robert Bradshaw
wrote:
[...]
> With over-allocation one might not even need the dense/sparse
> distinction--creating 1000 variables in a "sparse" manner would only
> need 10 reallocations. (There could still be the question of how
> expensive it is to do arit
Note that over allocating has a performance hit attached to it:
sage: P = PolynomialRing(QQ,500,'x')
sage: f = P.random_element()
sage: R = PolynomialRing(QQ,1000,'x')
sage: g = R(f)
sage: %timeit f*f
10 loops, best of 3: 18.2 µs per loop
sage: %timeit g*g
1 loops, best of 3: 32.3 µs per
On Nov 26, 2009, at 2:10 AM, Simon King wrote:
> Hi Robert!
>
> On Nov 26, 9:46 am, Robert Bradshaw
> 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
Hi Robert!
On Nov 26, 9:46 am, Robert Bradshaw
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)
I do not know in advance the number of variables needed.
It can be pre-computed, of course (and it would be equivalent to
actually running the whole algorithm), but we are definitely better
without this hindrance... Actually, I tried several things using var
("x_"+str(i)) and it is much better in m
Hi Nathann!
On Nov 26, 9:11 am, Nathann Cohen wrote:
> Ok, now I understand... ;-)
>
> The trouble is that obviously, I have no idea of how many variables I
> will need. I do no want to ask the user, as not having to say it is --
> really-- a relief !
I don't know exactly what you plan to do.
I
Hi Florent!
PS:
On Nov 26, 9:24 am, Florent Hivert
wrote:
> On Thu, Nov 26, 2009 at 01:16:09AM -0800, Simon King wrote:
> > > On Nov 26, 2009, at 12:35 AM, Florent Hivert wrote:
> > [...]
> > > I think this makes perfect sense...I'm actually surprised it's not
> > > implemented that way already.
Hi Florent!
On Nov 26, 9:24 am, Florent Hivert
wrote:
[...]
> I don't understand why what you say here is an answer to the following
> sentence of mine:
>
> Is there a problem in Symmetric Ideals if you have unused variables ?
You will always have an infinity of unused variables, of course: In
e
On Nov 26, 2009, at 1:16 AM, Simon King wrote:
> Hi Robert!
>
> On Nov 26, 8:43 am, Robert Bradshaw
> wrote:
>> On Nov 26, 2009, at 12:35 AM, Florent Hivert wrote:
>>> Though this could be improved by using a similar trick than
>>> doubling the size of a list when appending element, I'm not sure
Hi David!
On Nov 26, 9:07 am, David Kohel wrote:
> Rather I would say that "sparse" should be the default:
>
> P. = InfinitePolynomialRing(QQ, implementation="sparse")
No. The main purpose of InfinitePolynomialRing is the computation of
symmetric Groebner bases, and simply it turned out in examp
Hi Simon,
On Thu, Nov 26, 2009 at 01:16:09AM -0800, Simon King wrote:
> > On Nov 26, 2009, at 12:35 AM, Florent Hivert wrote:
> [...]
> > I think this makes perfect sense...I'm actually surprised it's not
> > implemented that way already.
>
> That's impossible.
>
> The whole point of In
Hi Robert!
On Nov 26, 8:43 am, Robert Bradshaw
wrote:
> On Nov 26, 2009, at 12:35 AM, Florent Hivert wrote:
[...]
> I think this makes perfect sense...I'm actually surprised it's not
> implemented that way already.
That's impossible.
The whole point of InfinitePolynomialRing is that you do *n
Ok, now I understand... ;-)
The trouble is that obviously, I have no idea of how many variables I
will need. I do no want to ask the user, as not having to say it is --
really-- a relief !
My other problem is that sometimes computation on symbolic variables
take a lot of time, and I think it come
Rather I would say that "sparse" should be the default:
P. = InfinitePolynomialRing(QQ, implementation="sparse")
Moreover, this syntax (and for gens, etc.) is inconsistent
with PolynomialRing. The syntax:
PolynomialRing(ring, integer, sparse=True)
would be a more coherent, where integer=Set(ZZ
Hi Nathann!
On Nov 26, 8:18 am, Nathann Cohen wrote:
[...]
> To understand my problem, just try this code :
>
> X. = InfinitePolynomialRing(RR)
> sum([x[i] for i in range(200)])
>
> Don't you think it is a bit long just to generate a sum ? I have to
> admit I do not know how this class is coded,
42 matches
Mail list logo
