23 views

Skip to first unread message

Sep 4, 2009, 6:04:34 AM9/4/09

to sage-...@googlegroups.com, libsingu...@googlegroups.com

On Friday 04 September 2009, Simon King wrote:

> Hi Kwankyu,

>

> On Sep 4, 8:02 am, Kwankyu <ekwan...@gmail.com> wrote:

> > In Singular, a ring can be defined with matrix ordering:

>

> [...]

>

> > In Sage, I am trying to construct a polynomial ring with matrix

> > ordering.

>

> AFAIK, it is not implemented, but I think that some people were

> working on it.

>

> It is in fact one of the things that I miss in Sage's polynomial rings

> (the other thing are supercommutative rings), so that I need to use

> the Singular interface rather than libsingular.

> Hi Kwankyu,

>

> On Sep 4, 8:02 am, Kwankyu <ekwan...@gmail.com> wrote:

> > In Singular, a ring can be defined with matrix ordering:

>

> [...]

>

> > In Sage, I am trying to construct a polynomial ring with matrix

> > ordering.

>

> AFAIK, it is not implemented, but I think that some people were

> working on it.

>

> It is in fact one of the things that I miss in Sage's polynomial rings

> (the other thing are supercommutative rings), so that I need to use

> the Singular interface rather than libsingular.

Simon et al,

if you design a Python-ic interface how to construct all the term orderings we

are still missing in Sage from Singular (e.g. weighted term orderings), then I

might find the time to implement them. For me, it is mainly an interface

design question, the libSingular part looks relatively easy (and we have

[libsingular-devel] now, where every of my questions was answered very quickly

so far!).

As a starting point, the TermOder objects might be interesting?

sage: A = random_matrix(ZZ,3,3)

sage: TermOrder(A)

???

Cheers,

Martin

PS: Did you play with the new libsingular functions functionality in

4.1.2.alpha? It might help you out with your supercommutative rings. The

libsingular functions are not feature complete yet though.

--

name: Martin Albrecht

_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99

_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

_www: http://www.informatik.uni-bremen.de/~malb

_jab: martinr...@jabber.ccc.de

Sep 4, 2009, 6:11:26 AM9/4/09

to sage-devel

Hi Simon!

the integration of

noncommutative algebras in Singular.

Maybe, you can give use a list, what you need.

Cheers,

Michael

> > It is in fact one of the things that I miss in Sage's polynomial rings

> > (the other thing are supercommutative rings),

Burcin will visit KL in octobre to work on
> > (the other thing are supercommutative rings),

the integration of

noncommutative algebras in Singular.

Maybe, you can give use a list, what you need.

Cheers,

Michael

Sep 4, 2009, 6:12:44 AM9/4/09

to sage-devel

Hi Martin!

> sage: A = random_matrix(ZZ,3,3)

> sage: TermOrder(A)

It looks very natural to me.

Michael

> sage: A = random_matrix(ZZ,3,3)

> sage: TermOrder(A)

Michael

Sep 4, 2009, 6:33:13 AM9/4/09

to sage-...@googlegroups.com, sage-comb...@googlegroups.com

Hi Simon,

Can you also provide example sage sessions showing how you think these

objects should be constructed?

I completely agree with Martin's previous comments on this. :)

> if you design a Python-ic interface how to construct all the term

> orderings we are still missing in Sage from Singular (e.g. weighted

> term orderings), then I might find the time to implement them. For

> me, it is mainly an interface design question, the libSingular part

> looks relatively easy (and we have [libsingular-devel] now, where

> every of my questions was answered very quickly so far!).

I was planning to send a separate message about this topic, but since

Michael brought it up here it goes...

Is there anybody else interested in a wrapper for the noncommutative

functionality provided by Singular?

Singular's capabilities are described in the manual here:

http://www.singular.uni-kl.de/Manual/latest/sing_356.htm#SEC397

If you're interested please write back with the following information

- what exactly are your needs

- ideas for a possible user interface (example Sage session)

- if you can contribute to the development (testing patches and

designing an interface is also a contribution)

BTW, I will also be working on using Singular for rational function

fields, and (as time permits) maybe also algebraic function fields. I

would appreciate any help in that area as well.

Cheers,

Burcin

Sep 4, 2009, 7:18:58 AM9/4/09

to sage-...@googlegroups.com, sage-comb...@googlegroups.com

Hi Burcin,

On Fri, Sep 4, 2009 at 7:33 AM, Burcin Erocal<bur...@erocal.org> wrote:

> Is there anybody else interested in a wrapper for the noncommutative

> functionality provided by Singular?

>

> Singular's capabilities are described in the manual here:

>

> http://www.singular.uni-kl.de/Manual/latest/sing_356.htm#SEC397

>

> If you're interested please write back with the following information

> - what exactly are your needs

> - ideas for a possible user interface (example Sage session)

> - if you can contribute to the development (testing patches and

> designing an interface is also a contribution)

Great! In quantum physics, one needs to work with quantum operator

that are non-commuting objects. There, we often need to check whether

commutator or anti-commutator of two composite operators are zero or not.

An example session would be:

----------

sage: A,B = nc_var('A,B')

sage: a,b,c,d = var('a,b,c,d')

sage: C = a*A + b*A*A

sage: D = d*B

sage: commutator(C, D)

a*d*commutator(A,B) + b*d*A*commutator(A,B) + b*d*commutator(A,B)*A

sage: commuator.define([A,B], 1)

sage commutator(A, B)

1

sage: commutator(C,D)

a*d + 2*b*d*A

------------

Thanks,

Golam

Sep 4, 2009, 7:27:25 AM9/4/09

to sage-devel

Hi all!

On Sep 4, 11:33 am, Burcin Erocal <bur...@erocal.org> wrote:

[...]

provided that one has

* Singular's "SuperCommutative" rings

* additional degree vectors (resp. matrix orderings where the first

matrix row is interpreted as degree vector).

SuperCommutative provides precisely one block of variables that

pairwise anticommute. However, it would be even nicer to have rings

with several anticommuting blocks.

I could imagine to create it (with additional degree vector) like

that:

sage: R.<a,b,c,d,e,f> = PolynomialRing(QQ, nc_blocks=[[0,1],[3,5]],

degrees=[1,1,2,3,3,3])

Then, R should be a graded commutative ring: two generators in degrees

1, one in degree 2, and three in degree 3, and the nc_blocks determine

that variables a,b,d,e,f are pairwise anti-commuting.

If only one anticommutative block is possible, then it could be:

sage: R.<c,a,b,d,e,f> = PolynomialRing(QQ, nc_block=[1,5], degrees=

[2,1,1,3,3,3])

> > if you design a Python-ic interface how to construct all the term

> > orderings we are still missing in Sage from Singular (e.g. weighted

> > term orderings), then I might find the time to implement them.

Currently, the ordering of a ring is determined by a string "name":

TermOrder.__init__(self, name='lex', n = 0, blocks=True)

respectively "order": PolynomialRing(base_ring, arg1=None, arg2=None,

sparse=False, order='degrevlex', names=None, name=None,

implementation=None)

Of course, it seems natural to define a matrix ordering by passing a

matrix:

sage: M = Matrix(2,2, [1,3,1,0])

sage: R.<x,y> = PolynomialRing(QQ,2,order=M)

But it is perhaps not so nice to break compatibility with the current

way of defining an ordering by strings.

Closer to Singular syntax would be

sage: R.<x,y> = PolynomialRing(QQ,2,order='M(1,3,1,0)')

But what about block orderings? If one allows a matrix ordering to be

defined by a matrix, then I guess the blocks should be listed:

sage: P.<a,b,c,d,e> = PolynomialRing(QQ,5,order=[M,'degrevlex'])

Or, if one goes with strings:

sage: P.<a,b,c,d,e> = PolynomialRing(QQ,5,order='M(1,3,1,0),degrevlex

(3)'])

As mentioned above, I would expect that the first row of a matrix

determines degrees (which is so in Singular). Hence, in the preceding

example, one would have

sage: a.degree()

1

sage: b.degree()

3

sage: c.degree() == d.degree() == e.degree() ==1

True

> Is there anybody else interested in a wrapper for the noncommutative

> functionality provided by Singular?

>

> Singular's capabilities are described in the manual here:

>

> http://www.singular.uni-kl.de/Manual/latest/sing_356.htm#SEC397

>

> If you're interested please write back with the following information

> - what exactly are your needs

> - ideas for a possible user interface (example Sage session)

My needs are restricted to the SuperCommutative algebras. The

implementation seems very efficient (two years ago I made some tests,

and the basic arithmetic is as fast as in the commutative case).

General non-commutative algebras are not needed to me, but would

certainly be nice to have. The nc_algebras in Singular are given by

two strictly upper triangular matrices, see

http://www.singular.uni-kl.de/Manual/latest/sing_404.htm#SEC445

So, one should expect that Sage should use two matrices as well.

However, there is one problem: In Singular, one would first define a

usual ring, since this allows you to define the two matrices (which

may contain polynomials, that's why you need the ring!), and only then

define the nc_algebra.

The example from the Singular manual would correspond to the following

Sage session:

sage: F.<Q> = FractionField(PolynomialRing(QQ,'Q'))

sage: R.<x,y,z> = PolynomialRing(F)

sage: C = Matrix(3,3, [0, Q^2, 1/Q^2, 0, 0, Q^2, 0,0,0])

sage: D = Matrix(3,3, [0, -Q*z, 1/Q*y, 0, 0, (-Q)*x, 0, 0, 0])

sage: ncF = F.nc_algebra(C,D)

It would be nice to have a one-line definition, but I doubt that this

would be easy, since one needs to name x,y,z when defining the matrix

D that is used when defining ncF.

> - if you can contribute to the development (testing patches and

> designing an interface is also a contribution)

Certainly I can do some tests.

Best regards,

Simon

On Sep 4, 11:33 am, Burcin Erocal <bur...@erocal.org> wrote:

[...]

> > Maybe, you can give use a list, what you need.

>

> Can you also provide example sage sessions showing how you think these

> objects should be constructed?

I need graded commutative rings, which can be easily constructed,
>

> Can you also provide example sage sessions showing how you think these

> objects should be constructed?

provided that one has

* Singular's "SuperCommutative" rings

* additional degree vectors (resp. matrix orderings where the first

matrix row is interpreted as degree vector).

SuperCommutative provides precisely one block of variables that

pairwise anticommute. However, it would be even nicer to have rings

with several anticommuting blocks.

I could imagine to create it (with additional degree vector) like

that:

sage: R.<a,b,c,d,e,f> = PolynomialRing(QQ, nc_blocks=[[0,1],[3,5]],

degrees=[1,1,2,3,3,3])

Then, R should be a graded commutative ring: two generators in degrees

1, one in degree 2, and three in degree 3, and the nc_blocks determine

that variables a,b,d,e,f are pairwise anti-commuting.

If only one anticommutative block is possible, then it could be:

sage: R.<c,a,b,d,e,f> = PolynomialRing(QQ, nc_block=[1,5], degrees=

[2,1,1,3,3,3])

> > if you design a Python-ic interface how to construct all the term

> > orderings we are still missing in Sage from Singular (e.g. weighted

> > term orderings), then I might find the time to implement them.

TermOrder.__init__(self, name='lex', n = 0, blocks=True)

respectively "order": PolynomialRing(base_ring, arg1=None, arg2=None,

sparse=False, order='degrevlex', names=None, name=None,

implementation=None)

Of course, it seems natural to define a matrix ordering by passing a

matrix:

sage: M = Matrix(2,2, [1,3,1,0])

sage: R.<x,y> = PolynomialRing(QQ,2,order=M)

But it is perhaps not so nice to break compatibility with the current

way of defining an ordering by strings.

Closer to Singular syntax would be

sage: R.<x,y> = PolynomialRing(QQ,2,order='M(1,3,1,0)')

But what about block orderings? If one allows a matrix ordering to be

defined by a matrix, then I guess the blocks should be listed:

sage: P.<a,b,c,d,e> = PolynomialRing(QQ,5,order=[M,'degrevlex'])

Or, if one goes with strings:

sage: P.<a,b,c,d,e> = PolynomialRing(QQ,5,order='M(1,3,1,0),degrevlex

(3)'])

As mentioned above, I would expect that the first row of a matrix

determines degrees (which is so in Singular). Hence, in the preceding

example, one would have

sage: a.degree()

1

sage: b.degree()

3

sage: c.degree() == d.degree() == e.degree() ==1

True

> Is there anybody else interested in a wrapper for the noncommutative

> functionality provided by Singular?

>

> Singular's capabilities are described in the manual here:

>

> http://www.singular.uni-kl.de/Manual/latest/sing_356.htm#SEC397

>

> If you're interested please write back with the following information

> - what exactly are your needs

> - ideas for a possible user interface (example Sage session)

implementation seems very efficient (two years ago I made some tests,

and the basic arithmetic is as fast as in the commutative case).

General non-commutative algebras are not needed to me, but would

certainly be nice to have. The nc_algebras in Singular are given by

two strictly upper triangular matrices, see

http://www.singular.uni-kl.de/Manual/latest/sing_404.htm#SEC445

So, one should expect that Sage should use two matrices as well.

However, there is one problem: In Singular, one would first define a

usual ring, since this allows you to define the two matrices (which

may contain polynomials, that's why you need the ring!), and only then

define the nc_algebra.

The example from the Singular manual would correspond to the following

Sage session:

sage: F.<Q> = FractionField(PolynomialRing(QQ,'Q'))

sage: R.<x,y,z> = PolynomialRing(F)

sage: C = Matrix(3,3, [0, Q^2, 1/Q^2, 0, 0, Q^2, 0,0,0])

sage: D = Matrix(3,3, [0, -Q*z, 1/Q*y, 0, 0, (-Q)*x, 0, 0, 0])

sage: ncF = F.nc_algebra(C,D)

It would be nice to have a one-line definition, but I doubt that this

would be easy, since one needs to name x,y,z when defining the matrix

D that is used when defining ncF.

> - if you can contribute to the development (testing patches and

> designing an interface is also a contribution)

Best regards,

Simon

Sep 4, 2009, 7:33:20 AM9/4/09

to sage-...@googlegroups.com

> Currently, the ordering of a ring is determined by a string "name":

> TermOrder.__init__(self, name='lex', n = 0, blocks=True)

> respectively "order": PolynomialRing(base_ring, arg1=None, arg2=None,

> sparse=False, order='degrevlex', names=None, name=None,

> implementation=None)

> TermOrder.__init__(self, name='lex', n = 0, blocks=True)

> respectively "order": PolynomialRing(base_ring, arg1=None, arg2=None,

> sparse=False, order='degrevlex', names=None, name=None,

> implementation=None)

> Of course, it seems natural to define a matrix ordering by passing a

> matrix:

> sage: M = Matrix(2,2, [1,3,1,0])

> sage: R.<x,y> = PolynomialRing(QQ,2,order=M)

>

> But it is perhaps not so nice to break compatibility with the current

> way of defining an ordering by strings.

>

> Closer to Singular syntax would be

> sage: R.<x,y> = PolynomialRing(QQ,2,order='M(1,3,1,0)')

Think this would be rather un-pythonic: converting an object into a string

instead of using it directly.

> But what about block orderings? If one allows a matrix ordering to be

> defined by a matrix, then I guess the blocks should be listed:

> sage: P.<a,b,c,d,e> = PolynomialRing(QQ,5,order=[M,'degrevlex'])

Have you seen this?

sage: TermOrder('deglex',3) + TermOrder('degrevlex',2)

deglex(3),degrevlex(2) term order

> Or, if one goes with strings:

> sage: P.<a,b,c,d,e> = PolynomialRing(QQ,5,order='M(1,3,1,0),degrevlex

> (3)'])

I would like to avoid this string business as much as possible. I find it

rather ugly (that's personal taste of course)

Cheers,

Martin

Sep 4, 2009, 7:45:16 AM9/4/09

to sage-devel

Hi Golam!

On Sep 4, 12:18 pm, Golam Mortuza Hossain <gmhoss...@gmail.com> wrote:

[...]

variables but about proper non-commutative polynomials over some base

ring. This has very little to do with symbolics. Moreover, I think it

is not pythonic to have a callable class "commutator" in the global

name space acting on polynomial rings.

However, I could imagine the following:

sage: F.<a,b,c,d> = FractionField(PolynomialRing(QQ,'a,b,c,d'))

sage: R.<A,B> = NCPolynomialRing(F)

# At this stage, R is a free non-commutative algebra

# whatever the answer is, but it would be an element of R and would

certainly not contain the word "commutator"

sage: R.nc_relation(A.commutator(B),1) # This would change R in

place, so by now it has some relations!!

sage: C.commutator(D)

a*d + 2*b*d*A

The advantage of this approach is that you can define any non-

commutative relation.

The disadvantages:

* Changing a ring in-place seems dangerous to me (can yield bugs that

are difficult to find)

* Changing a ring in-place is perhaps impracticable, since the

underlying implementation might completely change

* AFAIK, free non-commutative rings are only experimental in

Singular, and probably not yet ready for being wrapped in libSingular

Cheers,

Simon

On Sep 4, 12:18 pm, Golam Mortuza Hossain <gmhoss...@gmail.com> wrote:

[...]

> An example session would be:

> ----------

> sage: A,B = nc_var('A,B')

> sage: a,b,c,d = var('a,b,c,d')

>

> sage: C = a*A + b*A*A

> sage: D = d*B

> sage: commutator(C, D)

> a*d*commutator(A,B) + b*d*A*commutator(A,B) + b*d*commutator(A,B)*A

>

> sage: commuator.define([A,B], 1)

> sage commutator(A, B)

> 1

>

> sage: commutator(C,D)

> a*d + 2*b*d*A

> ------------

I think we are here not talking about non-commutative symbolic
> ----------

> sage: A,B = nc_var('A,B')

> sage: a,b,c,d = var('a,b,c,d')

>

> sage: C = a*A + b*A*A

> sage: D = d*B

> sage: commutator(C, D)

> a*d*commutator(A,B) + b*d*A*commutator(A,B) + b*d*commutator(A,B)*A

>

> sage: commuator.define([A,B], 1)

> sage commutator(A, B)

> 1

>

> sage: commutator(C,D)

> a*d + 2*b*d*A

> ------------

variables but about proper non-commutative polynomials over some base

ring. This has very little to do with symbolics. Moreover, I think it

is not pythonic to have a callable class "commutator" in the global

name space acting on polynomial rings.

However, I could imagine the following:

sage: F.<a,b,c,d> = FractionField(PolynomialRing(QQ,'a,b,c,d'))

sage: R.<A,B> = NCPolynomialRing(F)

# At this stage, R is a free non-commutative algebra

sage: C = a*A + b*A*A

sage: D = d*B

sage: C.commutator(D)
sage: D = d*B

# whatever the answer is, but it would be an element of R and would

certainly not contain the word "commutator"

sage: R.nc_relation(A.commutator(B),1) # This would change R in

place, so by now it has some relations!!

sage: C.commutator(D)

a*d + 2*b*d*A

The advantage of this approach is that you can define any non-

commutative relation.

The disadvantages:

* Changing a ring in-place seems dangerous to me (can yield bugs that

are difficult to find)

* Changing a ring in-place is perhaps impracticable, since the

underlying implementation might completely change

* AFAIK, free non-commutative rings are only experimental in

Singular, and probably not yet ready for being wrapped in libSingular

Cheers,

Simon

Sep 4, 2009, 7:51:32 AM9/4/09

to sage-devel

Hi Martin!

On Sep 4, 12:33 pm, Martin Albrecht <m...@informatik.uni-bremen.de>

wrote:

[...]

(1,3,1,0)'" was only in an attempt to provide compatibility with the

status quo, which is to define the ordering by a string, or by a

TermOrder object.

> Have you seen this?

>

> sage: TermOrder('deglex',3) + TermOrder('degrevlex',2)

> deglex(3),degrevlex(2) term order

Yes, but in fact I forgot about it. Reason: In most of the examples,

the term ordering of a polynomial ring is given by a string, rather

than first defining a TermOrder object.

Anyway, I agree that

('degrevlex',3))

is a good solution.

Best regards,

Simon

On Sep 4, 12:33 pm, Martin Albrecht <m...@informatik.uni-bremen.de>

wrote:

[...]

> > But it is perhaps not so nice to break compatibility with the current

> > way of defining an ordering by strings.

>

> > Closer to Singular syntax would be

> > sage: R.<x,y> = PolynomialRing(QQ,2,order='M(1,3,1,0)')

>

> Think this would be rather un-pythonic: converting an object into a string

> instead of using it directly.

I agree -- I don't like to use strings either. My suggestion "order='M
> > way of defining an ordering by strings.

>

> > Closer to Singular syntax would be

> > sage: R.<x,y> = PolynomialRing(QQ,2,order='M(1,3,1,0)')

>

> Think this would be rather un-pythonic: converting an object into a string

> instead of using it directly.

(1,3,1,0)'" was only in an attempt to provide compatibility with the

status quo, which is to define the ordering by a string, or by a

TermOrder object.

> Have you seen this?

>

> sage: TermOrder('deglex',3) + TermOrder('degrevlex',2)

> deglex(3),degrevlex(2) term order

the term ordering of a polynomial ring is given by a string, rather

than first defining a TermOrder object.

Anyway, I agree that

sage: M = Matrix(2,2, [1,3,1,0])

sage: P.<a,b,c,d,e> = PolynomialRing(QQ,5,order=TermOrder(M)+TermOrder
('degrevlex',3))

is a good solution.

Best regards,

Simon

Sep 4, 2009, 7:56:08 AM9/4/09

to sage-...@googlegroups.com

Hi Simon,

I should have mentioned earlier that long ago Michael Brickenstein and

I wrote a preliminary interface to Plural. You can find the patches

here:

http://trac.sagemath.org/sage_trac/ticket/4539

On Fri, 4 Sep 2009 04:27:25 -0700 (PDT)

Simon King <simon...@nuigalway.ie> wrote:

<snip>

> > Is there anybody else interested in a wrapper for the noncommutative

> > functionality provided by Singular?

> >

> > Singular's capabilities are described in the manual here:

> >

> > http://www.singular.uni-kl.de/Manual/latest/sing_356.htm#SEC397

> >

> > If you're interested please write back with the following

> > information

> > - what exactly are your needs

> > - ideas for a possible user interface (example Sage session)

>

> My needs are restricted to the SuperCommutative algebras. The

> implementation seems very efficient (two years ago I made some tests,

> and the basic arithmetic is as fast as in the commutative case).

>

> General non-commutative algebras are not needed to me, but would

> certainly be nice to have. The nc_algebras in Singular are given by

> two strictly upper triangular matrices, see

> http://www.singular.uni-kl.de/Manual/latest/sing_404.htm#SEC445

>

> So, one should expect that Sage should use two matrices as well.

This is not necessary. There is some code written by Michael that

converts the relations to a matrix, and passes that on to Singular

around line 396 of the patch here:

http://trac.sagemath.org/sage_trac/attachment/ticket/4539/plural_2.patch

Here is the doctest from that function:

sage: A.<x,y,z>=FreeAlgebra(QQ,3)

sage: G=A.g_algebra({y*x:-x*y})

sage: (x,y,z)=G.gens()

sage: x*y

x*y

sage: y*x

-x*y

sage: z*x

x*z

sage: (x,y,z)=A.gens()

sage: G=A.g_algebra({y*x:-x*y+1})

sage: (x,y,z)=G.gens()

sage: y*x

-x*y + 1

sage: (x,y,z)=A.gens()

sage: G=A.g_algebra({y*x:-x*y+z})

sage: (x,y,z)=G.gens()

sage: y*x

-x*y + z

IMHO, this is more user friendly compared to the Singular interface.

We shouldn't restrict ourselves to copying the Singular commands to

construct these objects.

We should also tie these to the FreeAlgebra stuff from the beginning.

Otherwise, we'll end up with a wrapper that lives independent of the

algebraic hierarchy like the PolyBoRi wrapper ended up being.

Thanks.

Cheers,

Burcin

Sep 4, 2009, 8:02:02 AM9/4/09

to sage-devel

Hi Burcin!

changing a ring in-place.

> IMHO, this is more user friendly compared to the Singular interface.

+1

I am glad that such interface already exists. Is it based on the

recent Singular implementation of free algebras, or is it independent?

Cheers,

Simon

> > So, one should expect that Sage should use two matrices as well.

>

> This is not necessary. There is some code written by Michael that

> converts the relations to a matrix, and passes that on to Singular

> around line 396 of the patch here:

>

> http://trac.sagemath.org/sage_trac/attachment/ticket/4539/plural_2.patch

>

> Here is the doctest from that function:

>

> sage: A.<x,y,z>=FreeAlgebra(QQ,3)

> sage: G=A.g_algebra({y*x:-x*y})

Yes, this is much better than my stupid suggestion to add relations by
>

> This is not necessary. There is some code written by Michael that

> converts the relations to a matrix, and passes that on to Singular

> around line 396 of the patch here:

>

> http://trac.sagemath.org/sage_trac/attachment/ticket/4539/plural_2.patch

>

> Here is the doctest from that function:

>

> sage: A.<x,y,z>=FreeAlgebra(QQ,3)

> sage: G=A.g_algebra({y*x:-x*y})

changing a ring in-place.

> IMHO, this is more user friendly compared to the Singular interface.

I am glad that such interface already exists. Is it based on the

recent Singular implementation of free algebras, or is it independent?

Cheers,

Simon

Sep 4, 2009, 8:03:43 AM9/4/09

to sage-devel

Hi!

emulation on top of our existing rings and only work up to some

degree.

I think, this is very interesting and tricky stuff, but I wouldn't

recommend to do anything now about that.

I hope, that we get the best results out of this week.

Michael

> * AFAIK, free non-commutative rings are only experimental in

> Singular, and probably not yet ready for being wrapped in libSingular

AFAIK (and I hope, that's more) free algebras in Singular are only an
> Singular, and probably not yet ready for being wrapped in libSingular

emulation on top of our existing rings and only work up to some

degree.

I think, this is very interesting and tricky stuff, but I wouldn't

recommend to do anything now about that.

I hope, that we get the best results out of this week.

Michael

Sep 4, 2009, 8:23:00 AM9/4/09

to sage-...@googlegroups.com

Do you mean the Letterplace (why do they capitalize the names of

these things?!?) extension [1] ?

[1] http://www.singular.uni-kl.de/Manual/latest/sing_425.htm#SEC478

I am not sure if using this directly for arithmetic from Sage is a good

idea, since you need to give a bound on the degree of each variable

that will appear in your computation (and we also need to fix the

printing anyway). I was thinking of hooking up the GB functions only to

the appropriate places (which don't exist at the moment).

Unfortunately this requires giving more care and attention to the

FreeAlgebra stuff in Sage than I have time for, so it will have to wait

till someone else takes it up.

Cheers,

Burcin

Sep 4, 2009, 8:39:02 AM9/4/09

to sage-...@googlegroups.com

It's independent. It was just a quick effort to use Plural from Sage. I

didn't have time afterwards to follow up and fix the remaining

problems. I don't even know if the patches still apply.

I'm hoping that things will be easier now since there is a much cleaner

interface to libSingular (many thanks Martin and Michael!). Though

sage/algebras/ is still one of the most rusty corners of sage. :)

Cheers,

Burcin

Sep 4, 2009, 8:54:08 AM9/4/09

to sage-devel

Hi Burcin, Hi Michael,

conference talks.

> Unfortunately this requires giving more care and attention to the

> FreeAlgebra stuff in Sage than I have time for, so it will have to wait

> till someone else takes it up.

Well, Michael seemed to agree that Letterplace is of more experimental

character.

But certainly the G-algebra stuff in Singular (where the non-

commutativity is provided by two matrices) is mature enough, and I

understood from the previous posts that it is already more or less

wrapped, and we are talking about the interface.

Certainly,

But what exactly is the input data? Would you allow general relations,

such as {y*x*y: -z+x*y}? Or must the keys of the dictionary be

monomials of degree 2, since otherwise you run into non-decidable

questions? In this case, I guess your interface is equivalent to

Singular's way of defining a G-algebra, but certainly nicer.

Since there is http://trac.sagemath.org/sage_trac/ticket/4539 and it

says "need work": What exactly is needed to do? Is it just a decision

about the interface? In that case, I am +1 to your suggestion!

Cheers,

Simon

> Do you mean the Letterplace (why do they capitalize the names of

> these things?!?) extension [1] ?

>

> [1]http://www.singular.uni-kl.de/Manual/latest/sing_425.htm#SEC478

I think so. I didn't use it myself, but I heard it being mentioned in
> these things?!?) extension [1] ?

>

> [1]http://www.singular.uni-kl.de/Manual/latest/sing_425.htm#SEC478

conference talks.

> Unfortunately this requires giving more care and attention to the

> FreeAlgebra stuff in Sage than I have time for, so it will have to wait

> till someone else takes it up.

character.

But certainly the G-algebra stuff in Singular (where the non-

commutativity is provided by two matrices) is mature enough, and I

understood from the previous posts that it is already more or less

wrapped, and we are talking about the interface.

Certainly,

sage: A.<x,y,z>=FreeAlgebra(QQ,3)

sage: G=A.g_algebra({y*x:-x*y})

is nice.
sage: G=A.g_algebra({y*x:-x*y})

But what exactly is the input data? Would you allow general relations,

such as {y*x*y: -z+x*y}? Or must the keys of the dictionary be

monomials of degree 2, since otherwise you run into non-decidable

questions? In this case, I guess your interface is equivalent to

Singular's way of defining a G-algebra, but certainly nicer.

Since there is http://trac.sagemath.org/sage_trac/ticket/4539 and it

says "need work": What exactly is needed to do? Is it just a decision

about the interface? In that case, I am +1 to your suggestion!

Cheers,

Simon

Sep 4, 2009, 9:52:00 AM9/4/09

to sage-...@googlegroups.com

You're right, it is equivalent to the G-algebras defined in Singular.

Checking these conditions is one of the items on the list below. :)

> Since there is http://trac.sagemath.org/sage_trac/ticket/4539 and it

> says "need work": What exactly is needed to do? Is it just a decision

> about the interface? In that case, I am +1 to your suggestion!

No, unfortunately it's not that easy.

- We just subclassed MPolynomialRing_libsingular to create the ring

then, elements are instances of MPolynomial_libsingular. These

inherit from CommutativeRing and CommutativeRingElement

respectively. :)

One would have to create new classes for the elements and the parent

in the appropriate place of the hierarchy. Refactoring the

libSingular calls in the above classes helps tremendously here. :)

- Check if the commutativity relations satisfy the conditions for a

G-algebra as defined here:

http://www.singular.uni-kl.de/Manual/latest/sing_420.htm#SEC461

- sort out coercion

- wrap various functions defined by Singular:

http://www.singular.uni-kl.de/Manual/latest/sing_390.htm#SEC431

- find a way to wrap the predefined structures here:

http://www.singular.uni-kl.de/Manual/latest/sing_538.htm#SEC591

- etc.

Any volunteers?

Cheers,

Burcin

Sep 4, 2009, 10:15:17 AM9/4/09

to sage-...@googlegroups.com

Hi!

> - sort out coercion

> - wrap various functions defined by Singular:

> http://www.singular.uni-kl.de/Manual/latest/sing_390.htm#SEC431

This part won't require hard Singular knowledge.

We probably will have to add some missing pieces to LibSingularFunction

to make the wrapping really easy.

I think, we can need every helping hand here.

Cheers,

Michael

> - sort out coercion

> - wrap various functions defined by Singular:

> http://www.singular.uni-kl.de/Manual/latest/sing_390.htm#SEC431

We probably will have to add some missing pieces to LibSingularFunction

to make the wrapping really easy.

I think, we can need every helping hand here.

Cheers,

Michael

Sep 4, 2009, 11:39:57 AM9/4/09

to sage-devel

Hi Burcin!

> > Since there ishttp://trac.sagemath.org/sage_trac/ticket/4539and it

Certainly I don't know enough about the Singular internals. So far my

impression was that Singular/Plural has two data types /

implementations of non-commutative rings: One for SuperCommutative

rings and one for general G-algebras. And I thought that both somehow

rely on the commutative rings, internally.

So, do you re-implement Singular/Plural nc-algorithms (subclassing

MPolynomialRing_libsingular and building on top of it), or are you

directly wrapping Singular/Plural data types?

Or was your statement about how Sage's G-algebras should fit into the

hierarchy of algebras? Then the following seems to make sense to me:

* Ring(ParentWithGens)

* CommutativeRing(Ring)

* CommutativeAlgebra(CommutativeRing)

* Algebra(Ring)

* PolynomialRing_general(Algebra)

* GAlgebra(PolynomialRing_general) # new

* GAlgebra_libsingular(GAlgebra) # new

* PolynomialRing_supercommutative(G_Algebra) # new

# (perhaps with a _libsingular subclass)

* PolynomialRing_commutative(GAlgebra,

CommutativeAlgebra)

# this currently is (PolynomialRing_general,

CommutativeAlgebra)

* MPolynomialRing_libsingular etc.

Cheers,

Simon

> > Since there ishttp://trac.sagemath.org/sage_trac/ticket/4539and it

> > says "need work": What exactly is needed to do? Is it just a decision

> > about the interface? In that case, I am +1 to your suggestion!

>

> No, unfortunately it's not that easy.

>

> - We just subclassed MPolynomialRing_libsingular to create the ring

> then, elements are instances of MPolynomial_libsingular. These

> inherit from CommutativeRing and CommutativeRingElement

> respectively. :)

>

> One would have to create new classes for the elements and the parent

> in the appropriate place of the hierarchy. Refactoring the

> libSingular calls in the above classes helps tremendously here. :)

I am not sure what you mean.
> > about the interface? In that case, I am +1 to your suggestion!

>

> No, unfortunately it's not that easy.

>

> - We just subclassed MPolynomialRing_libsingular to create the ring

> then, elements are instances of MPolynomial_libsingular. These

> inherit from CommutativeRing and CommutativeRingElement

> respectively. :)

>

> One would have to create new classes for the elements and the parent

> in the appropriate place of the hierarchy. Refactoring the

> libSingular calls in the above classes helps tremendously here. :)

Certainly I don't know enough about the Singular internals. So far my

impression was that Singular/Plural has two data types /

implementations of non-commutative rings: One for SuperCommutative

rings and one for general G-algebras. And I thought that both somehow

rely on the commutative rings, internally.

So, do you re-implement Singular/Plural nc-algorithms (subclassing

MPolynomialRing_libsingular and building on top of it), or are you

directly wrapping Singular/Plural data types?

Or was your statement about how Sage's G-algebras should fit into the

hierarchy of algebras? Then the following seems to make sense to me:

* Ring(ParentWithGens)

* CommutativeRing(Ring)

* CommutativeAlgebra(CommutativeRing)

* Algebra(Ring)

* PolynomialRing_general(Algebra)

* GAlgebra(PolynomialRing_general) # new

* GAlgebra_libsingular(GAlgebra) # new

* PolynomialRing_supercommutative(G_Algebra) # new

# (perhaps with a _libsingular subclass)

* PolynomialRing_commutative(GAlgebra,

CommutativeAlgebra)

# this currently is (PolynomialRing_general,

CommutativeAlgebra)

* MPolynomialRing_libsingular etc.

Cheers,

Simon

Sep 4, 2009, 1:16:15 PM9/4/09

to sage-devel

Hi Burcin, Michael, Simon,

Please let me explain the current non-commutative Singular

conventions:

1. the only way to create a G-algebra is to endow a commutative

polynomial ring (NOT a qring!) with a non-commutative structure

2. in order to create a GR-algebra:

compute two-sided GB in G-algebra and use it to define a factor

ring.

{{{

// example Singular script:

// 1:

ring r;

def g=nc_algebra(-1,0); setring g;

g;

// 2:

ideal q=twostd(ideal(x^2, y^2, z^2));

qring gr = q;

gr; // exterior algebra in x,y,z

x*x; // gives 0: since gr is internally a SCA

}}}

Therefore the only "legal" steps are:

A. define G-algebra (using matrices C & D) (see jjPlural_mat_mat in

iparith.cc)

B. compute a two-sided(!) GB there (see jjTWOSTD in iparith.cc)

(the standard "std" command computes a left (!) GB in non-commutative

case)

C. create non-commutative factor ring (see jiA_QRING in ipassign.cc)

(factors of GR-algebras are allowed)

Special multiplicative structure (e.g. supercommutative) will be

automatically detected in A. & C. whereas forcefully calling the

internal API (e.g. sca_*) is prone of subtle side effects.

Cheers,

Oleksandr

> > Since there ishttp://trac.sagemath.org/sage_trac/ticket/4539and it

Please let me explain the current non-commutative Singular

conventions:

1. the only way to create a G-algebra is to endow a commutative

polynomial ring (NOT a qring!) with a non-commutative structure

2. in order to create a GR-algebra:

compute two-sided GB in G-algebra and use it to define a factor

ring.

{{{

// example Singular script:

// 1:

ring r;

def g=nc_algebra(-1,0); setring g;

g;

// 2:

ideal q=twostd(ideal(x^2, y^2, z^2));

qring gr = q;

gr; // exterior algebra in x,y,z

x*x; // gives 0: since gr is internally a SCA

}}}

Therefore the only "legal" steps are:

A. define G-algebra (using matrices C & D) (see jjPlural_mat_mat in

iparith.cc)

B. compute a two-sided(!) GB there (see jjTWOSTD in iparith.cc)

(the standard "std" command computes a left (!) GB in non-commutative

case)

C. create non-commutative factor ring (see jiA_QRING in ipassign.cc)

(factors of GR-algebras are allowed)

Special multiplicative structure (e.g. supercommutative) will be

automatically detected in A. & C. whereas forcefully calling the

internal API (e.g. sca_*) is prone of subtle side effects.

Cheers,

Oleksandr

Sep 4, 2009, 1:52:40 PM9/4/09

to sage-devel

Hello,

i would like to add that commutative variables in supercommutative

algebras may be local (whereas non-commutative variables must be

global), e.g:

{{{

LIB "nctools.lib";

ring r=0,(x,y,z), (ds(1), dp(2)); // x is local!

def E = superCommutative(2,3);setring E; E;

// characteristic : 0

// number of vars : 3

// block 1 : ordering ds

// : names x

// block 2 : ordering dp

// : names y z

// block 3 : ordering C

// noncommutative relations:

// zy=-yz

// quotient ring from ideal

_[1]=y2

_[2]=z2

> y*y; // SCA!

0

> 1+ x + y + z; // y > z > 1 > x !

y+z+1+x

}}}

This functionality was initially intended to support computation of

direct images of sheaves in certain cases but by no means limited to

that.

The Singular's "std" uses a modified Mora variant of BBA in such a

"local" case.

Feel free to experiment with this feature :)

Please do let us know about your favorite and yet missing non-

commutative features!

Any feedback is greatly appreciated!

Cheers,

Oleksandr

i would like to add that commutative variables in supercommutative

algebras may be local (whereas non-commutative variables must be

global), e.g:

{{{

LIB "nctools.lib";

ring r=0,(x,y,z), (ds(1), dp(2)); // x is local!

def E = superCommutative(2,3);setring E; E;

// characteristic : 0

// number of vars : 3

// block 1 : ordering ds

// : names x

// block 2 : ordering dp

// : names y z

// block 3 : ordering C

// noncommutative relations:

// zy=-yz

// quotient ring from ideal

_[1]=y2

_[2]=z2

> y*y; // SCA!

0

> 1+ x + y + z; // y > z > 1 > x !

y+z+1+x

}}}

This functionality was initially intended to support computation of

direct images of sheaves in certain cases but by no means limited to

that.

The Singular's "std" uses a modified Mora variant of BBA in such a

"local" case.

Feel free to experiment with this feature :)

Please do let us know about your favorite and yet missing non-

commutative features!

Any feedback is greatly appreciated!

Cheers,

Oleksandr

Sep 4, 2009, 2:23:30 PM9/4/09

to sage-devel

Hi Oleksandr!

On Sep 4, 6:52 pm, Oleksandr <mot...@rhrk.uni-kl.de> wrote:

[...]

available in the commutative case. I think it would be nice to

distinguish not two but three cases: commutative, supercommutative,

and general G-algebras.

This suggestion comes from the observation that many algorithms for

commutative rings work in the supercommutative (or graded commutative)

setting as well, but Singular refuses them since they would not work

for general G-algebras. Therefore, in my applications I had in some

cases to work around and implement these algorithms as library

functions.

Three examples:

* Kernel/preimage of maps

* Hilbert polynomial/function: This certainly makes sense for

(weighted) homogeneous ideals in graded commutative rings.

* AFAIK dim (Krull dimension) makes sense in the graded commutative

case as well.

Best regards,

Simon

On Sep 4, 6:52 pm, Oleksandr <mot...@rhrk.uni-kl.de> wrote:

[...]

> Please do let us know about your favorite and yet missing non-

> commutative features!

>

> Any feedback is greatly appreciated!

AFAIK, the Singular kernel has a marker for functions that are only
> commutative features!

>

> Any feedback is greatly appreciated!

available in the commutative case. I think it would be nice to

distinguish not two but three cases: commutative, supercommutative,

and general G-algebras.

This suggestion comes from the observation that many algorithms for

commutative rings work in the supercommutative (or graded commutative)

setting as well, but Singular refuses them since they would not work

for general G-algebras. Therefore, in my applications I had in some

cases to work around and implement these algorithms as library

functions.

Three examples:

* Kernel/preimage of maps

* Hilbert polynomial/function: This certainly makes sense for

(weighted) homogeneous ideals in graded commutative rings.

* AFAIK dim (Krull dimension) makes sense in the graded commutative

case as well.

Best regards,

Simon

Sep 5, 2009, 5:53:03 AM9/5/09

to sage-devel

Hi Simon,

Thank you! That's definitely something to think about.

First of all, please, let me explain that Singular kernel doesn't have

any such markers... it's actually the Singular interpreter who cares

at the moment about command availability in general non-commutative

case. These markers are used to disable commands which are still only

commutative-minded and thus not guaranteed to work and compute

something sensible.

AFAIK It was done in such a static way mainly due to the ability to

remove the non-commutative subsystem in _compile_time_ without any

traces...

Well, if go on defining more cases and assigning more markers to

commands, wouldn't it make Singular less and less maintainable?

In fact i fail to see how non-commutativity is soooooo qualitatively

different from say homogeneity of input...

I would propose to move these checks into kernel feature

implementations so that they can be done in run time by every

individual feature, which definitely should know more about its

abilities than the Singular interpreter. This way we can guarantee

their correctness (or at least a sensible error message) even when

being called directly by Sage in any setting.

What do you think?

Best regards,

Oleksandr

First of all, please, let me explain that Singular kernel doesn't have

any such markers... it's actually the Singular interpreter who cares

at the moment about command availability in general non-commutative

case. These markers are used to disable commands which are still only

commutative-minded and thus not guaranteed to work and compute

something sensible.

AFAIK It was done in such a static way mainly due to the ability to

remove the non-commutative subsystem in _compile_time_ without any

traces...

Well, if go on defining more cases and assigning more markers to

commands, wouldn't it make Singular less and less maintainable?

In fact i fail to see how non-commutativity is soooooo qualitatively

different from say homogeneity of input...

I would propose to move these checks into kernel feature

implementations so that they can be done in run time by every

individual feature, which definitely should know more about its

abilities than the Singular interpreter. This way we can guarantee

their correctness (or at least a sensible error message) even when

being called directly by Sage in any setting.

What do you think?

Best regards,

Oleksandr

Sep 5, 2009, 6:34:36 AM9/5/09

to sage-devel

Hi Oleksandr,

On Sep 5, 10:53 am, Oleksandr <mot...@rhrk.uni-kl.de> wrote:

[...]

iparith.cc, or is this not kernel? Here, one typically sees lines such

as

{jjSTD_HILB_WP, STD_CMD, IDEAL_CMD, 4

NO_PLURAL}

{jjREDUCE5, REDUCE_CMD, IDEAL_CMD/*or set by p*/, 5

ALLOW_PLURAL}

By "markers", I was referring to these NO_PLURAL / ALLOW_PLURAL

markers.

[...]

Perhaps it was my misunderstanding that iparith.cc is in the kernel.

I would agree that it makes mathematically sense to let each function

check by itself whether the input is suitable (e.g., jjSTD_HILB_WP

checks whether we are in a graded commutative weighted homogeneous

setting, in which Hilbert driven standard basis computation makes

sense).

However, I am not sure if Hans or Gert-Martin would agree that it

makes practically sense. After all, testing for complicated conditions

under which a function works costs time. So, why not have a very

simple test (commutative vs. non-commutative) that is immediate?

Therefore my suggestion to have markers, say ALLOW_G_ALGEBRA,

ALLOW_SC_ALGEBRA, NO_PLURAL.

Cheers,

Simon

On Sep 5, 10:53 am, Oleksandr <mot...@rhrk.uni-kl.de> wrote:

[...]

> First of all, please, let me explain that Singular kernel doesn't have

> any such markers...

Really? The only part of the Singular kernel that I ever met is
> any such markers...

iparith.cc, or is this not kernel? Here, one typically sees lines such

as

{jjSTD_HILB_WP, STD_CMD, IDEAL_CMD, 4

NO_PLURAL}

{jjREDUCE5, REDUCE_CMD, IDEAL_CMD/*or set by p*/, 5

ALLOW_PLURAL}

By "markers", I was referring to these NO_PLURAL / ALLOW_PLURAL

markers.

[...]

> I would propose to move these checks into kernel feature

> implementations so that they can be done in run time by every

> individual feature, [...]
> implementations so that they can be done in run time by every

Perhaps it was my misunderstanding that iparith.cc is in the kernel.

I would agree that it makes mathematically sense to let each function

check by itself whether the input is suitable (e.g., jjSTD_HILB_WP

checks whether we are in a graded commutative weighted homogeneous

setting, in which Hilbert driven standard basis computation makes

sense).

However, I am not sure if Hans or Gert-Martin would agree that it

makes practically sense. After all, testing for complicated conditions

under which a function works costs time. So, why not have a very

simple test (commutative vs. non-commutative) that is immediate?

Therefore my suggestion to have markers, say ALLOW_G_ALGEBRA,

ALLOW_SC_ALGEBRA, NO_PLURAL.

Cheers,

Simon

Sep 5, 2009, 8:11:07 AM9/5/09

to sage-devel

Dear Simon,

On Sep 5, 12:34 pm, Simon King <simon.k...@nuigalway.ie> wrote:

> On Sep 5, 10:53 am, Oleksandr <mot...@rhrk.uni-kl.de> wrote:

> > First of all, please, let me explain that Singular kernel doesn't have

> > any such markers...

> Really? The only part of the Singular kernel that I ever met is

> iparith.cc, or is this not kernel? Here, one typically sees lines such as

> {jjSTD_HILB_WP, STD_CMD, IDEAL_CMD, 4

> NO_PLURAL}

> {jjREDUCE5, REDUCE_CMD, IDEAL_CMD/*or set by p*/, 5

> ALLOW_PLURAL}

> By "markers", I was referring to these NO_PLURAL / ALLOW_PLURAL

> markers.

Yes exactly - this is a part of Singular interpreter. Functions like

jjSTD_HILB_WP should (ideally) _only_ delegate the call to the

appropriate

kernel function (say kStd) while doing some interpreter-related checks

and

convert interpreter's data structures (e.g. leftv, attributes) into

something

kernel-understandable (e.g. poly/ideal/intvec).

> > I would propose to move these checks into kernel feature

> > implementations so that they can be done in run time by every

> > individual feature, [...]

> Perhaps it was my misunderstanding that iparith.cc is in the kernel.

I agree that at the moment the boundary between the Singular

interpreter

(which is the /Singular directory) and the kernel (/kernel) is a way

tooooo weak:

ideally there should be NO parts of singular kernel logic inside

interpreter wrappers (jj***)...

> I would agree that it makes mathematically sense to let each function

> check by itself whether the input is suitable (e.g.,

ALLOW_PLURAL-marker functionality.

Specific tests (detections) are performed _once_ during the algebra

construction.

Afterwards checks like "is non-commutative" or "is supercommutative"

are _cheap_

(see rIsPluralRing and rIsSCA).

> Therefore my suggestion to have markers, say ALLOW_G_ALGEBRA,

> ALLOW_SC_ALGEBRA, NO_PLURAL.

You see, the idea was to provide a framework in which one can easily

implement

any particular GR-algebra as a separate kernel extension with its own

multiplication routines and SB-related algorithms in a virtual-

overloading manner.

At the moment SCA is just an example of how this can be done...

Moreover, we already have a separate experimental implementation where

multiplication

uses formulas for specific automatically detectable G-algebras (e.g.

Weyl) instead of raw

relations+caching (as in the general G-algebra). I guess these

formulas will eventually be

merged into the framework...

More importantly: if Sage accesses the Singular kernel directly -

these Singular interpreter markers cannot help Sage...

Regards,

Oleksandr

On Sep 5, 12:34 pm, Simon King <simon.k...@nuigalway.ie> wrote:

> On Sep 5, 10:53 am, Oleksandr <mot...@rhrk.uni-kl.de> wrote:

> > First of all, please, let me explain that Singular kernel doesn't have

> > any such markers...

> Really? The only part of the Singular kernel that I ever met is

> iparith.cc, or is this not kernel? Here, one typically sees lines such as

> {jjSTD_HILB_WP, STD_CMD, IDEAL_CMD, 4

> NO_PLURAL}

> {jjREDUCE5, REDUCE_CMD, IDEAL_CMD/*or set by p*/, 5

> ALLOW_PLURAL}

> By "markers", I was referring to these NO_PLURAL / ALLOW_PLURAL

> markers.

jjSTD_HILB_WP should (ideally) _only_ delegate the call to the

appropriate

kernel function (say kStd) while doing some interpreter-related checks

and

convert interpreter's data structures (e.g. leftv, attributes) into

something

kernel-understandable (e.g. poly/ideal/intvec).

> > I would propose to move these checks into kernel feature

> > implementations so that they can be done in run time by every

> > individual feature, [...]

> Perhaps it was my misunderstanding that iparith.cc is in the kernel.

interpreter

(which is the /Singular directory) and the kernel (/kernel) is a way

tooooo weak:

ideally there should be NO parts of singular kernel logic inside

interpreter wrappers (jj***)...

> I would agree that it makes mathematically sense to let each function

> check by itself whether the input is suitable (e.g.,

> checks whether we are in a graded commutative weighted homogeneous

> setting, in which Hilbert driven standard basis computation makes

> sense).

> However, I am not sure if Hans or Gert-Martin would agree that it

> makes practically sense. After all, testing for complicated conditions

> under which a function works costs time.

> So, why not have a very simple test (commutative vs. non-commutative) that is immediate?

Well, this "simple test" is exactly the existing static NO_PLURAL/
> setting, in which Hilbert driven standard basis computation makes

> sense).

> However, I am not sure if Hans or Gert-Martin would agree that it

> makes practically sense. After all, testing for complicated conditions

> under which a function works costs time.

> So, why not have a very simple test (commutative vs. non-commutative) that is immediate?

ALLOW_PLURAL-marker functionality.

Specific tests (detections) are performed _once_ during the algebra

construction.

Afterwards checks like "is non-commutative" or "is supercommutative"

are _cheap_

(see rIsPluralRing and rIsSCA).

> Therefore my suggestion to have markers, say ALLOW_G_ALGEBRA,

> ALLOW_SC_ALGEBRA, NO_PLURAL.

implement

any particular GR-algebra as a separate kernel extension with its own

multiplication routines and SB-related algorithms in a virtual-

overloading manner.

At the moment SCA is just an example of how this can be done...

Moreover, we already have a separate experimental implementation where

multiplication

uses formulas for specific automatically detectable G-algebras (e.g.

Weyl) instead of raw

relations+caching (as in the general G-algebra). I guess these

formulas will eventually be

merged into the framework...

More importantly: if Sage accesses the Singular kernel directly -

these Singular interpreter markers cannot help Sage...

Regards,

Oleksandr

Sep 5, 2009, 11:47:48 AM9/5/09

to sage-devel

[..]

un-pythonic, as it entirely relies on working with strings.

Namely:

...

name = []

for block_order in self.blocks + other.blocks:

nom = block_order.singular_str()

name.append("%s(%d)"%(inv_singular_name_mapping.get

(nom,nom), len(block_order)))

name = ",".join(name)

return TermOrder(name, len(self)+len(other))

In other words, for each block, the defining string for the order in

Singular is translated into a defining string for the order in Sage,

by a dictionary lookup (inv_singular_name_mapping.get(nom,nom), then

everything is concatenated and given as the input to

TermOrder.__init__.

Problem: singular_str() for a matrix order will be M(1,3,1,0,...),

where the number of integers between the brackets depends on the

lengths. This can't be dealt with by a simple dictionary lookup.

So, a proper support of Matrix orders will be more work, and wrapping

things in libsingular will not suffice.

Best regards,

Simon

> Think this would be rather un-pythonic: converting an object into a string

> instead of using it directly.

>

> > But what about block orderings? If one allows a matrix ordering to be

> > defined by a matrix, then I guess the blocks should be listed:

> > sage: P.<a,b,c,d,e> = PolynomialRing(QQ,5,order=[M,'degrevlex'])

>

> Have you seen this?

>

> sage: TermOrder('deglex',3) + TermOrder('degrevlex',2)

> deglex(3),degrevlex(2) term order

Meanwhile I've also seen the code of TermOrder.__add__. It is rather
> instead of using it directly.

>

> > But what about block orderings? If one allows a matrix ordering to be

> > defined by a matrix, then I guess the blocks should be listed:

> > sage: P.<a,b,c,d,e> = PolynomialRing(QQ,5,order=[M,'degrevlex'])

>

> Have you seen this?

>

> sage: TermOrder('deglex',3) + TermOrder('degrevlex',2)

> deglex(3),degrevlex(2) term order

un-pythonic, as it entirely relies on working with strings.

Namely:

...

name = []

for block_order in self.blocks + other.blocks:

nom = block_order.singular_str()

name.append("%s(%d)"%(inv_singular_name_mapping.get

(nom,nom), len(block_order)))

name = ",".join(name)

return TermOrder(name, len(self)+len(other))

In other words, for each block, the defining string for the order in

Singular is translated into a defining string for the order in Sage,

by a dictionary lookup (inv_singular_name_mapping.get(nom,nom), then

everything is concatenated and given as the input to

TermOrder.__init__.

Problem: singular_str() for a matrix order will be M(1,3,1,0,...),

where the number of integers between the brackets depends on the

lengths. This can't be dealt with by a simple dictionary lookup.

So, a proper support of Matrix orders will be more work, and wrapping

things in libsingular will not suffice.

Best regards,

Simon

Sep 5, 2009, 12:38:59 PM9/5/09

to sage-devel

Hi!

> More importantly: if Sage accesses the Singular kernel directly -

> these Singular interpreter markers cannot help Sage...

Independent from what is the right solution, I would like to mention,

that I worked with Martin on using the same interface to the kernel

functions as the Singular interpreter does.

So maybe, SingularKernelFunction already checks the markers.

Cheers,

Michael

> More importantly: if Sage accesses the Singular kernel directly -

> these Singular interpreter markers cannot help Sage...

that I worked with Martin on using the same interface to the kernel

functions as the Singular interpreter does.

So maybe, SingularKernelFunction already checks the markers.

Cheers,

Michael

Sep 5, 2009, 2:32:46 PM9/5/09

to sage-devel

Hi,

How about this syntax?

> sage: A = random_matrix(ZZ,3,3)

> sage: TermOrder("weight",matrix=A)

following the Magma syntax for weight ordering. I certainly prefer the

term weight ordering than matrix ordering.

The following is the description of the weight ordering in the Magma

documentation:

Definition (given n weight vectors W1, ... Wn from Q^n): s < t iff

there exists 1 ≤i ≤n such that s.Wj = t.Wj for 1 ≤j < i and s.Wi <

t.Wi. The order is specified by the arguments ("weight", Q) where Q is

a sequence of n^2 non-negative integers or rationals describing the n

weight vectors of length n (in row major order).

Kwankyu

How about this syntax?

> sage: A = random_matrix(ZZ,3,3)

> sage: TermOrder("weight",matrix=A)

following the Magma syntax for weight ordering. I certainly prefer the

term weight ordering than matrix ordering.

The following is the description of the weight ordering in the Magma

documentation:

Definition (given n weight vectors W1, ... Wn from Q^n): s < t iff

there exists 1 ≤i ≤n such that s.Wj = t.Wj for 1 ≤j < i and s.Wi <

t.Wi. The order is specified by the arguments ("weight", Q) where Q is

a sequence of n^2 non-negative integers or rationals describing the n

weight vectors of length n (in row major order).

Kwankyu

Sep 5, 2009, 5:42:43 PM9/5/09

to sage-devel

Hi!

On Sep 5, 7:32 pm, Kwankyu <ekwan...@gmail.com> wrote:

> How about this syntax?

>

> > sage: A = random_matrix(ZZ,3,3)

> > sage: TermOrder("weight",matrix=A)

>

> following the Magma syntax for weight ordering. I certainly prefer the

> term weight ordering than matrix ordering.

I don't know what is more common. I learned it under the name

"matrix", not "weight". By "weight", I would understand that one just

gets a degree vector for the ring generators (as in "weighted

homogeneous"), for example a "weighted degree lexicographic order".

Anyway, it seems redundant to give both a string ("weight" or

"matrix") *and* a matrix.

So, this syntax is shorter and clearer:

sage: TermOrder(A)

Note that when we talk about the input syntax, we would certainly not

be able to solve the problem with the __add__ method that I mentioned

in a previous post. I think that problem can only be solved by

improving the internal representation of the order.

Cheers,

Simon

On Sep 5, 7:32 pm, Kwankyu <ekwan...@gmail.com> wrote:

> How about this syntax?

>

> > sage: A = random_matrix(ZZ,3,3)

> > sage: TermOrder("weight",matrix=A)

>

> following the Magma syntax for weight ordering. I certainly prefer the

> term weight ordering than matrix ordering.

"matrix", not "weight". By "weight", I would understand that one just

gets a degree vector for the ring generators (as in "weighted

homogeneous"), for example a "weighted degree lexicographic order".

Anyway, it seems redundant to give both a string ("weight" or

"matrix") *and* a matrix.

So, this syntax is shorter and clearer:

sage: TermOrder(A)

Note that when we talk about the input syntax, we would certainly not

be able to solve the problem with the __add__ method that I mentioned

in a previous post. I think that problem can only be solved by

improving the internal representation of the order.

Cheers,

Simon

Sep 5, 2009, 9:05:23 PM9/5/09

to sage-...@googlegroups.com

> Meanwhile I've also seen the code of TermOrder.__add__. It is rather

> un-pythonic, as it entirely relies on working with strings.

<snip>> un-pythonic, as it entirely relies on working with strings.

> So, a proper support of Matrix orders will be more work, and wrapping

> things in libsingular will not suffice.

Sure, it is rather ad-hoc at the moment. As soon as we have an interface we

want to expose to the user (maybe TermOder(Matrix) suffices?) we can fix that!

Sep 7, 2009, 8:34:45 AM9/7/09

to sage-devel

Hi Martin,

What about Sage implementation for

1. weighting vector(s) "a(w1, w2...wn)",

2. free module orderings (e.g. c/C) mixed somewhere in between? Does

Sage have such a concept?

In Sage i'd imagine something like:

{{{

TermOrder = WeightVector(2,5) + ModuleOrder('c') + WeightVector(-1,-2)

+ MatrixOrder(1,1,0,-1)

}}}

corresponding to:

{{{

> ring R =0,(x, y), (a(2,5), c, a(-1,-2), M(1,1,0,-1)); R;

// characteristic : 0

// number of vars : 2

// block 1 : ordering a

// : names x y

// : weights 2 5

// block 2 : ordering c

// block 3 : ordering a

// : names x y

// : weights -1 -2

// block 4 : ordering M

// : names x y

// : weights 1 1

// : weights 0 -1

> deg(x); // note that the 1st "a"/"M"/weighted ordering is used for "deg"

2

> deg(y);

5

}}}

Best regards,

Oleksandr

On Sep 4, 1:33 pm, Martin Albrecht <m...@informatik.uni-bremen.de>

wrote:

> _jab: martinralbre...@jabber.ccc.de

What about Sage implementation for

1. weighting vector(s) "a(w1, w2...wn)",

2. free module orderings (e.g. c/C) mixed somewhere in between? Does

Sage have such a concept?

In Sage i'd imagine something like:

{{{

TermOrder = WeightVector(2,5) + ModuleOrder('c') + WeightVector(-1,-2)

+ MatrixOrder(1,1,0,-1)

}}}

corresponding to:

{{{

> ring R =0,(x, y), (a(2,5), c, a(-1,-2), M(1,1,0,-1)); R;

// characteristic : 0

// number of vars : 2

// block 1 : ordering a

// : names x y

// : weights 2 5

// block 2 : ordering c

// block 3 : ordering a

// : names x y

// : weights -1 -2

// block 4 : ordering M

// : names x y

// : weights 1 1

// : weights 0 -1

> deg(x); // note that the 1st "a"/"M"/weighted ordering is used for "deg"

2

> deg(y);

5

}}}

Best regards,

Oleksandr

On Sep 4, 1:33 pm, Martin Albrecht <m...@informatik.uni-bremen.de>

wrote: