Roman,

That's great to know. I wonder why such an example is not included in the help pages. For polynomials in the example that I did above, it produces the same answer with tdeg(y,x) ordering,

alias(a=RootOf(_Z^4+_Z+1)):
Groebner:-Basis({x^2+a*y,x^3+(a^2+1)},
tdeg(y,x),characteristic=2);

              2                   3        3    2       2
            [x  + a y, y x + 1 + a  + a, (a  + a ) x + y ]

With tdeg(x,y) instead it gives the same polynomials, but in the reverse order.

The same with plex(x,y) - the order of polynomials in the answer is reversed, comparing to Magma,

Magma("k<a>:=GF(16);
P<x,y>:=PolynomialRing(k,2);
I:=ideal<P|x^2+a*y,x^3+(1+a^2)>;
GroebnerBasis(I);");

  "-------------------------------------

        [
            x + a^9*y^2,
            y^3 + a^13
        ]

        "

Groebner:-Basis({x^2+a*y,x^3+(a^2+1)},
plex(x,y),characteristic=2);

                       2    3    3            3   2
                 [1 + a  + a  + y , x + (a + a ) y ]

Is this "works as designed"?

Alec

Roman,

That's great to know. I wonder why such an example is not included in the help pages. For polynomials in the example that I did above, it produces the same answer with tdeg(y,x) ordering,

alias(a=RootOf(_Z^4+_Z+1)):
Groebner:-Basis({x^2+a*y,x^3+(a^2+1)},
tdeg(y,x),characteristic=2);

              2                   3        3    2       2
            [x  + a y, y x + 1 + a  + a, (a  + a ) x + y ]

With tdeg(x,y) instead it gives the same polynomials, but in the reverse order.

The same with plex(x,y) - the order of polynomials in the answer is reversed, comparing to Magma,

Magma("k<a>:=GF(16);
P<x,y>:=PolynomialRing(k,2);
I:=ideal<P|x^2+a*y,x^3+(1+a^2)>;
GroebnerBasis(I);");

  "-------------------------------------

        [
            x + a^9*y^2,
            y^3 + a^13
        ]

        "

Groebner:-Basis({x^2+a*y,x^3+(a^2+1)},
plex(x,y),characteristic=2);

                       2    3    3            3   2
                 [1 + a  + a  + y , x + (a + a ) y ]

Is this "works as designed"?

Alec

The manuals in the Maple Documentation Center may be useful.

Alec

The manuals in the Maple Documentation Center may be useful.

Alec

Yes, the coefficients should be in that field. GF(4) doesn't contain 4, 5, and 6. It's elements are 0, 1, a, and a+1. GF(16) also doesn't contain them, but they can be interpreted in it using base 2 representation. 4 is 100 in base 2, so it is represented as a^2. 5 is 101, and can be represented as a^2+1, and 6 is 110, with corresponding representation a^2+a. Working with GF, such a transformation can be done using input.

k:=GF(2,4):

k:-input(4);

                                   2
                                  T

k:-input(5);

                                     2
                                1 + T

k:-input(6);

                                     2
                                T + T

However, that can't be used directly to construct a polynomial in Maple,

f:=x^2+(k:-input(2))*y;
Error, invalid terms in product

use k in f:=x^2+input(2)*y end;
Error, (in ^) modp1: invalid arguments to function Powmod

Alec

Yes, the coefficients should be in that field. GF(4) doesn't contain 4, 5, and 6. It's elements are 0, 1, a, and a+1. GF(16) also doesn't contain them, but they can be interpreted in it using base 2 representation. 4 is 100 in base 2, so it is represented as a^2. 5 is 101, and can be represented as a^2+1, and 6 is 110, with corresponding representation a^2+a. Working with GF, such a transformation can be done using input.

k:=GF(2,4):

k:-input(4);

                                   2
                                  T

k:-input(5);

                                     2
                                1 + T

k:-input(6);

                                     2
                                T + T

However, that can't be used directly to construct a polynomial in Maple,

f:=x^2+(k:-input(2))*y;
Error, invalid terms in product

use k in f:=x^2+input(2)*y end;
Error, (in ^) modp1: invalid arguments to function Powmod

Alec

Both equations, after putting the long square root in the rhs and other terms in the lhs, and taking squares of both sides, become linear equations for the variable we are trying to find. So, assuming that s is not 0, there may be either one solution (as in the real case), or no solutions - if the rhs actually equals -lhs and not lhs.

Alec

Both equations, after putting the long square root in the rhs and other terms in the lhs, and taking squares of both sides, become linear equations for the variable we are trying to find. So, assuming that s is not 0, there may be either one solution (as in the real case), or no solutions - if the rhs actually equals -lhs and not lhs.

Alec

Submitting SCR on this site has a few problems, mentioned many times.

In particular, the latest versions, Maple 12.01 and Maple 12.02 are not included. A copy of the report is not available after submitting.

The legal notice at the end is rather strange: All submissions become the property of Waterloo Maple Inc.

Does that mean that if I submitted a bug, then I don't have rights on it anymore and can't post it in any other place?

Thus far, my personal experience tells completely opposite - the bugs submitted through the SCR are not fixed, while the bugs posted on this site have some chances to get fixed - still less than 20%, but greater than 0% for bugs submitted through SCR and not posted in the forums.

Alec

Submitting SCR on this site has a few problems, mentioned many times.

In particular, the latest versions, Maple 12.01 and Maple 12.02 are not included. A copy of the report is not available after submitting.

The legal notice at the end is rather strange: All submissions become the property of Waterloo Maple Inc.

Does that mean that if I submitted a bug, then I don't have rights on it anymore and can't post it in any other place?

Thus far, my personal experience tells completely opposite - the bugs submitted through the SCR are not fixed, while the bugs posted on this site have some chances to get fixed - still less than 20%, but greater than 0% for bugs submitted through SCR and not posted in the forums.

Alec

You can add single (not double) quotes to prevent (so called premature) evaluation,

plot( 'Z(x,1000,0.001)' ,x=0.6..1.1)

or

plot( 'Z'(x,1000,0.001),x=0.6..1.1)

Sometimes the initial value, something like z=1.25 in fsolve helps, or a range - something like z=1..2, added as a second argument - I mean helps for fsolve, not for plotting. And sometimes increasing of Digits helps.

Alec

You can add single (not double) quotes to prevent (so called premature) evaluation,

plot( 'Z(x,1000,0.001)' ,x=0.6..1.1)

or

plot( 'Z'(x,1000,0.001),x=0.6..1.1)

Sometimes the initial value, something like z=1.25 in fsolve helps, or a range - something like z=1..2, added as a second argument - I mean helps for fsolve, not for plotting. And sometimes increasing of Digits helps.

Alec

I am apologizing for saying that code is usually unreadable. It seems like that just because usually I am trying to read the code producing a bug, trying to fix it. And these pieces of code, yes, are usually unreadable. But I shouldn't say that about the entire code. Just well-written code doesn't have bugs, and I rarely read it.

In this particular case, I was frustrated trying to fix a strange bug. The location of it was rather clear - in the procedure I cited above. But I couldn't exactly point to a place causing it, so that it could be fixed.

It's not that easy to compare older and newer code. I would say that older code is more artistic and more brilliant. Newer code is often using templates, which sometimes produce comical results (such as "if 0<1 then..."), but "without loss of performance" as I was told once. A lot of bugs in newer code are caused by copying a part of one procedure into another one, without changing corresponding details (such as changing one elliptic function name to another, or one of graph types to another one.)

Some pieces of (relatively) new code I like - for instance, Warnings package is written very well. Certainly, anything written by Paul DeMarco, Dave Linder, Alex Potapchik, Joe Riel (in alphabetical order) should be very good, too - I have no doubts about that. The people that I don't know (or, more precisely, whose code I've never seen, on this site, or in the Maple newsgroup) - that's a different story.

Alec

I am apologizing for saying that code is usually unreadable. It seems like that just because usually I am trying to read the code producing a bug, trying to fix it. And these pieces of code, yes, are usually unreadable. But I shouldn't say that about the entire code. Just well-written code doesn't have bugs, and I rarely read it.

In this particular case, I was frustrated trying to fix a strange bug. The location of it was rather clear - in the procedure I cited above. But I couldn't exactly point to a place causing it, so that it could be fixed.

It's not that easy to compare older and newer code. I would say that older code is more artistic and more brilliant. Newer code is often using templates, which sometimes produce comical results (such as "if 0<1 then..."), but "without loss of performance" as I was told once. A lot of bugs in newer code are caused by copying a part of one procedure into another one, without changing corresponding details (such as changing one elliptic function name to another, or one of graph types to another one.)

Some pieces of (relatively) new code I like - for instance, Warnings package is written very well. Certainly, anything written by Paul DeMarco, Dave Linder, Alex Potapchik, Joe Riel (in alphabetical order) should be very good, too - I have no doubts about that. The people that I don't know (or, more precisely, whose code I've never seen, on this site, or in the Maple newsgroup) - that's a different story.

Alec

Snarks are not just any bridgeless cubic graphs - they are also connected and have chromatic number 4 (which makes them non-planar). So my guess is that, in French, or not, if somebody is talking about bridgeless cubic graphs, he or she would use term "bridgeless cubic graph". Talking about snarks in English, people use term "snark" instead of "connected bridgeless cubic graph with chromatic number 4" because it is more or less standard term for that. Whether it is a standard term in French, or some other term is used, I don't know.

Since Lewis Carrol's "The Hunting of the Snark" is translated to French as "La Chasse au Snark", it seems natural if the term "Snark" was used in French as well.

Alec