Opened 10 years ago

Closed 10 years ago

# facFirstWeyl computes wrong result in Master (but not in SW)...

Reported by: Owned by: Oleksandr somebody major 3-1-6 and higher singular-libs 3-1-6 nc, factor levandovskyy

### Description (last modified by Oleksandr )

The test `Long/ncfactor_lee_l.tst` from the SW' test-suite:

```ring R = 0,(x,d),dp; def r = nc_algebra(1,1);setring(r);
poly L = 10x5d4+26x4d5+47x5d2-97x4d3;facFirstWeyl(L);
```

Current Master Singular returns wrong output (according to `testNCfac` and entry `[2]` is plainly wrong!):

```[1]:
[1]:
1
[2]:
10x4d2+26x3d3+47x4-117x3d-78x2d2+117x2+156xd-156
[3]:
x
[4]:
d
[5]:
d
[2]:
[1]:
1
[2]:
x
[3]:
x
[4]:
d
[5]:
d
[3]:
[1]:
1
[2]:
xd-3
[3]:
10x3d2+26x2d3+47x3-117x2d-52xd2+52d
[4]:
xd-1
[4]:
[1]:
1
[2]:
xd-3
[3]:
x
[4]:
x
[5]:
[1]:
1
[2]:
10x4d2+26x3d3+47x4-117x3d-78x2d2+117x2+156xd-156
[3]:
d
[4]:
xd-1
[6]:
[1]:
1
[2]:
xd-3
[3]:
x
[4]:
x
[5]:
x
[6]:
10xd3+26d4+47xd-107d2-47
[7]:
[1]:
1
[2]:
x
[3]:
xd-2
[4]:
x
[5]:
x
[6]:
10xd3+26d4+47xd-107d2-47
[8]:
[1]:
1
[2]:
x
[3]:
x
[4]:
xd-1
[5]:
x
[6]:
10xd3+26d4+47xd-107d2-47
[9]:
[1]:
1
[2]:
x
[3]:
x
[4]:
x
[5]:
x
[6]:
d
[7]:
10xd3+26d4+47xd-107d2-47
[10]:
[1]:
1
[2]:
x
[3]:
x
[4]:
x
[5]:
x
[6]:
10xd2+26d3+47x-97d
[7]:
d
[11]:
[1]:
1
[2]:
x
[3]:
x
[4]:
x
[5]:
x
[6]:
10xd2+26d3+47x-97d
[7]:
d
[8]:
d
```

Master Build GIT-ID is `79c9b876326058a6d1c21eccb9b6080c1ae3a93e` (with a BS and FLINT related fix). It was build as follows:

```Singular for x86_64-Linux version 3-1-7 (3170)  Aug 27 2013 16:55:57
with
factory(@(#) factoryVersion = 3.1.6),libfac(3.1.6,December 2012),
dynamic modules,dynamic p_Procs,OM_CHECK=0,OM_TRACK=0,random=1378012097
CC= gcc -O2 -w -fomit-frame-pointer -pipe -DNDEBUG -DOM_NDEBUG -Dx86_64_Linux -DHAVE_CONFIG_H,
CXX= g++ -O2 -w -fomit-frame-pointer -fno-rtti -I.. -I/GITHUB/w/MASTER -pipe -DNDEBUG -DOM_NDEBUG -Dx86_64_Linux -DHAVE_CONFIG_H (4.8.1 20130725 (prerelease))
```

### comment:1 Changed 10 years ago by Oleksandr

Note that the current SW gives short and correct (according to `testNCfac`) output:

```[1]:
[1]:
1
[2]:
10x4d2+26x3d3+47x4-117x3d-78x2d2+117x2+156xd-156
[3]:
x
[4]:
d
[5]:
d
[2]:
[1]:
1
[2]:
10x4d2+26x3d3+47x4-117x3d-78x2d2+117x2+156xd-156
[3]:
d
[4]:
xd-1
[3]:
[1]:
1
[2]:
xd-3
[3]:
10x3d2+26x2d3+47x3-117x2d-52xd2+52d
[4]:
xd-1
[4]:
[1]:
1
[2]:
xd-3
[3]:
x
[4]:
x
[5]:
x
[6]:
10xd3+26d4+47xd-107d2-47
[5]:
[1]:
1
[2]:
x
[3]:
xd-2
[4]:
x
[5]:
x
[6]:
10xd3+26d4+47xd-107d2-47
[6]:
[1]:
1
[2]:
x
[3]:
x
[4]:
xd-1
[5]:
x
[6]:
10xd3+26d4+47xd-107d2-47
[7]:
[1]:
1
[2]:
x
[3]:
x
[4]:
x
[5]:
x
[6]:
d
[7]:
10xd3+26d4+47xd-107d2-47
[8]:
[1]:
1
[2]:
x
[3]:
x
[4]:
x
[5]:
x
[6]:
10xd2+26d3+47x-97d
[7]:
d
[8]:
d
```

### comment:2 Changed 10 years ago by Oleksandr

Description: modified (diff)

### comment:3 Changed 10 years ago by mlee

I've send Albert Heinle (the author of ncfactor.lib) an email to check 6358cfe22f06e105e3de6a6241edfa4cb812aa2e again as SW and master's ncfactor.lib differ by this commit.

### comment:4 Changed 10 years ago by Albert Heinle

Hello @all,

Martin Lee sent me the Bug description, and I could locate and fix the bug. I sent the fixed version of the code to him.

Short description of the problem: I found a way to increase the versatility of the results and added a function called "checkForHomogInhomogInterchangability". I submitted it recently, thus in 3-1-6 is everything okay still, as outlined above by motsak. In this function, there was sort of an off-by-one error at a block, that was rarely visited. Thus I did not catch it before (sorry for that)...

But now everything is okay again. Thank your for checking my library.

With best wishes,

Albert Heinle

### comment:5 Changed 10 years ago by mlee

Resolution: → fixed new → closed
Note: See TracTickets for help on using tickets.