BUG in sort from general.lib

[Oleksandr]

There was a bug or (which is the same) an undocumented feature in "sort" from "general.lib":

LIB "general.lib";
> ring r; r;
//   characteristic : 32003
//   number of vars : 3
//        block   1 : ordering dp
//                  : names    x y z
//        block   2 : ordering C
> module M = [0, 1, 1, 0], [1, 0, 0, 1]; M; // Due to "C":
M[1]=gen(3)+gen(2)
M[2]=gen(4)+gen(1)
> lead(M); // Thus:
_[1]=gen(3)
_[2]=gen(4)        
> sort(lead(M), "c, dp")[1]; // since gen(4) <_{c} gen(3):
_[1]=gen(4)
_[2]=gen(3)
> sort(M, "c, dp")[1]; // BUG: this result contradicts the above one!
_[1]=gen(3)+gen(2)
_[2]=gen(4)+gen(1)
> lead(sort(M, "c, dp")[1]); // HENCE: lead(sort(M)) != sort(lead(M)) ! :(
_[1]=gen(3)
_[2]=gen(4)

Note that mapping the whole inout to the internally constructed ring may change leading terms!

My fix: only lead(id) should be mapped.

I only tested the most simple situation...

[Oleksandr]

My assumption was: sort sorts elements (polynomials/vectors) wrt some new ordering by sorting their CURRENT leading terms. Is that correct?

[Oleksandr]

it seems that my assumption was wrong:

i will remove changes and improve the description of "sort":

If a new ordering (string) is given elements are sorted by considering leading terms wrt the new ordering!