Opened 14 years ago

Closed 14 years ago

#152 closed bug (invalid)

BUG in sort from general.lib

Reported by: Oleksandr Owned by: Oleksandr
Priority: trivial Milestone: 3-1-1
Component: singular-libs Version: 3-1-0
Keywords: sort Cc: hannes, greuel


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":
> lead(M); // Thus:
> sort(lead(M), "c, dp")[1]; // since gen(4) <_{c} gen(3):
> sort(M, "c, dp")[1]; // BUG: this result contradicts the above one!
> lead(sort(M, "c, dp")[1]); // HENCE: lead(sort(M)) != sort(lead(M)) ! :(

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...

Change History (3)

comment:1 Changed 14 years ago by Oleksandr

Status: newassigned

comment:2 Changed 14 years ago by Oleksandr

Cc: greuel added

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

comment:3 Changed 14 years ago by Oleksandr

Resolution: invalid
Status: assignedclosed

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!

Note: See TracTickets for help on using tickets.