Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#542 closed bug (wontfix)

ringlist-driven definition of ring fails

Reported by: aheinle@… Owned by: somebody
Priority: major Milestone: 3-2-0 and higher
Component: dontKnow Version: 3-1-6
Keywords: ringlist, ring Cc:

Description

Hello Singular-team,

I am using Singular's functionality to define a ring via a ringlist.

But there is some unexpected behaviour I am encountering, and I cannot find a reason for it in the documentation. Hence, I am assuming that I encountered a bug.

Consider the following minimal working example:

 ring S = 0,(x1,s1,x2,s2),dp;
 matrix C[4][4] = 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1;
 print(C);
 matrix D[4][4] = 0,s1,0,0,0,0,0,0,0,0,0,s2,0,0,0,0;
 print(D);
 def s = nc_algebra (C,D);//Defines the 2nd shift algebra
 setring(s);
 basering; // Output the ring as desired
 list l = ringlist(s);
 l;
 l[2][2] = "x2";//Swapping the position of x2,s2 and s1
 l[2][4] = "s2";//-"-
 l[2][3] = "s1";//-"-
 print(l[2]);
 l[6][1,2] =0;l[6][3,4]=0;
 l[6][1,3] = s1;
 l[6][2,4] = s2;
 print (l[6]);
 def foungBugOrNot = ring(l);
 setring(foungBugOrNot);
 basering;//Gives wrong ring

What this code basically does is to define the 2nd shift algebra. In my programs, I want x1,x2 be in the first two positions and s1,s2 in the last two. That is why I use the ringlist structure to change the order. In the end, I also update the respective noncommutative relations. After I set this ring, the relations are totally messed up, and this is not a shift algebra any more.

In particular, the output of the first basering; call will output

//   characteristic : 0
//   number of vars : 4
//        block   1 : ordering dp
//                  : names    x1 s1 x2 s2
//        block   2 : ordering C
//   noncommutative relations:
//    s1x1=x1*s1+s1
//    s2x2=x2*s2+s2

and the output of the second basering; call is

//   characteristic : 0
//   number of vars : 4
//        block   1 : ordering dp
//                  : names    x1 x2 s1 s2
//        block   2 : ordering C
//   noncommutative relations:
//    s1x1=x1*s1+x2
//    s2x2=x2*s2+s2

Here, one can see that s1x1 = x1*s1 + x2 does not make any sense, and does not coincide with my definition of the matrix in l[6]. One can run the code to verify that all definitions are correct to get the same ring back as s, but with switched positions of the variables.

I use Singular 3-1-6 on an Ubuntu 12.04LTS version.

Best regards,

Albert Heinle

Change History (9)

comment:1 in reply to:  description ; Changed 11 years ago by kroeker@…

Replying to aheinle@…:

[...]

Albert Heinle

yes its a bug and it seems that when defining the noncommutative relations, the variable indices of the original ring are used. (you could guessed it by looking at the resulting ringlist(foungBugOrNot) where instead of the entry s1 you would see x2)

Until it is fixed, you can get the desired ring by following hack:

 l[6][1,2] =0;
l[6][3,4]=0;
 l[6][1,3] = x2; // want s1 ( in current ring variable index 3, in old:  3rd variable x2!) 
 l[6][2,4] = s2; // want s2 ( index 4, old 4rd variable s2 )
 print (l[6]);
 def foungBugOrNot = ring(l);
 setring(foungBugOrNot);
 // now the ringlist became magically fixed *G
 ringlist(basering);

comment:2 in reply to:  1 Changed 11 years ago by aheinle@…

Replying to kroeker@…:

Replying to aheinle@…:

[...]

Albert Heinle

[...]

Hi! Thanks for the quick reply. As I am working on code for a Singular library, I should not deploy the hack there ;-) I will wait then till the bug is fixed before I submit my next version... Or try to find another way to change the ring structure...

Best,

Albert

comment:3 Changed 11 years ago by Oleksandr

Keywords: noncommutative removed
Summary: ringlist-driven definition of ring fails. Noncommutative relations mixed up.ringlist-driven definition of ring fails

comment:4 Changed 11 years ago by Oleksandr

This has nothing to do with NC-rings! Consider the mapping of quotient ideal in the following commutative example:

ring S = 0,(a,b),dp; qring QQ = std(b); QQ;

//   characteristic : 0
//   number of vars : 2
//        block   1 : ordering dp
//                  : names    a b
//        block   2 : ordering C
// quotient ring from ideal
_[1]=b


list l = ringlist(basering); def t = l[2][1]; l[2][1] = l[2][2]; l[2][2] = t; def SS = ring(l); setring SS; SS;

//   characteristic : 0
//   number of vars : 2
//        block   1 : ordering dp
//                  : names    b a
//        block   2 : ordering C
// quotient ring from ideal
_[1]=a

comment:5 in reply to:  4 Changed 11 years ago by anonymous

Replying to motsak:

[...]

Oha, apparently it goes beyond noncommutativity. I just added it as I encountered it in the noncommutative environment. Thanks for checking! Thus I agree, the keyword noncommutativity does not apply then.

comment:6 Changed 11 years ago by hannes

Resolution: wontfix
Status: newclosed

This occurs with all data which depends on the soon to be constructed ring. This ring does not (yet) exist, so all this happens to be in the current (old) ring and will be mapped via fetch to the new one. I will add a remark to the ringlist description. (spielwiese: a1e807a999ad81c88502c684ee93531e7840ea82)

comment:7 in reply to:  6 Changed 11 years ago by kroeker@…

Replying to hannes:

[...] wontfix

@Albert Heinle : Here are two suggestions, how to solve your issue

 ring S = 0,(x1,s1,x2,s2),dp;
 matrix C[4][4] = 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1;
 print(C);
 matrix D[4][4] = 0,s1,0,0,0,0,0,0,0,0,0,s2,0,0,0,0;
 print(D);
 def s = nc_algebra (C,D);//Defines the 2nd shift algebra
 setring(s);
 basering; // Output the ring as desired
 list l = ringlist(s);
 l;

 ring SMOD = 0,(x1,x2,s1,s2),dp;

 matrix C[4][4] = 1,1,1,1, 1,1,1,1, 1,1,1,1, 1,1,1,1;
 matrix D[4][4] = 0,0,s1,0, 0,0,0,s2, 0,0,0,0, 0,0,0,0;
 print(D);
 def smod = nc_algebra (C,D);//Defines the 2nd shift algebra
 setring(smod);
 basering;

or

 ring S = 0,(x1,s1,x2,s2),dp;
 matrix C[4][4] = 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1;
 print(C);
 matrix D[4][4] = 0,s1,0,0,0,0,0,0,0,0,0,s2,0,0,0,0;
 print(D);
 def s = nc_algebra (C,D);//Defines the 2nd shift algebra
 setring(s);
 basering; // Output the ring as desired
 list l = ringlist(s);
 l;
 
 l[2][2] = "x2";//Swapping the position of x2,s2 and s1
 l[2][4] = "s2";//-"-
 l[2][3] = "s1";//-"-
 print(l[2]);
 l[6][1,2] =0;l[6][3,4]=0;
 l[6][1,3] = s1;
 l[6][2,4] = s2;
 print (l[6]);
 string sl6 = string(l[6]);

 def sintermediate = ring(l);
 setring sintermediate;

 list ltmp = ringlist(basering);
 string strcmd = " matrix D[4][4]="+ sl6+ ";";
 execute(strcmd);
 ltmp[6] = D;

 def smod = ring(ltmp);
 setring smod;
 basering;

@Albert Heinle if you don't like the suggestions or cannot adopt it for your code, feel free to contact me directly (see www.iag.uni-hannover.de/team.html ) and also attach your library code

@Hannes whatever strategy is used (fetch or imap for some data) to construct the ring from ringlist, it seems that the relation representation in ringlist[5] and ringlist[6] is unfortunate for ring construction. However, I do not have a good solution for that, too. Probably it needs some thinking

Jakob

comment:8 Changed 11 years ago by aheinle@…

Well, I would still call it unexpected behaviour, but if you leave a note, I think people won't try it then.

My example was a minimal working one, but in general I will need that for the n'th shift algebra... Therefore the roundabout solutions should be a bit more involved. But don't worry, I will figure something out, and if I am stuck, then I will contact you @Jakob. Thank you again for the offer.

Best to you all and Merry Christmas!

Albert

comment:9 Changed 11 years ago by aheinle@…

Okay, I have chosen the path through an intermediate ring to solve this problem. For anyone, who also encounters this problem in the future, here is the workaround for the nth shift algebra:

    def r = basering;
    list tempRingList = ringlist(r);
    tempRingList = delete(tempRingList,6);
    list the_vars;
    for (i = 1; i<=nvars(r); i++)
    {the_vars[i] = var(i);}
    int maybeDInWrongPos;
    poly tempVariable;
    for (i = 1; i<=size(the_vars) div 2; i++)
    {//Swapping the variables as needed
      maybeDInWrongPos = 1;
      if (the_vars[i + size(the_vars) div 2]*the_vars[i]
    	  -the_vars[i]*the_vars[i + size(the_vars) div 2]
	  == the_vars[i + size(the_vars) div 2])
      {
    	i++; continue;
      }
      //If we enter this line, there is a break with our property
      //condition
      for (j = i+1; j<=size(the_vars); j++)
      {
    	if (the_vars[j]*the_vars[i]-the_vars[i]*the_vars[j]==the_vars[j])
    	{//In this case, we matched a var x to a repective s
      	  tempVariable = the_vars[i + size(the_vars) div 2];
    	  the_vars[i + size(the_vars) div 2] = the_vars[j];
    	  the_vars[j] = tempVariable;
    	  maybeDInWrongPos = 0;
      	  break;
    	}//In this case, we matched a var x to a repective s
      }
      if (maybeDInWrongPos)
      {//var(i) is actually a s, not an x
    	print("i has to be pushed to the end.");
    	tempVariable = the_vars[i];
    	the_vars = delete(the_vars, i);
    	the_vars = the_vars + list(tempVariable);
       	continue;
      }//var(i) is actually a s, not an x
    }//Swapping the variables as needed
    for (i = 1; i<=size(the_vars); i++)
    {tempRingList[2][i] = string(the_vars[i]);}
    matrix DTemp[nvars(r)][nvars(r)];
    for (i = 1; i<=ncols(DTemp) div 2; i++)
    {
      DTemp[i,i + nvars(r) div 2] = the_vars[i + nvars(r) div 2];
    }
    tempRingList = tempRingList + list(DTemp);
    def tempRing = ring(tempRingList);
    setring(tempRing);
    //We have to go through an intermediate ring, as there is some strange
    //behaviour in Singular concerning the correctness of the matrix D.
    // See www.singular.uni-kl.de:8002/trac/ticket/542 for details.
    matrix DTemp = imap(r, DTemp);
    list tempRingList2 = ringlist(tempRing);
    tempRingList2[6]= DTemp;
    def tempRing2 = ring(tempRingList2);
    setring(tempRing2);

Have a merry christmas!

Albert

Note: See TracTickets for help on using tickets.