corrections/review of bfct.lib

[Oleksandr]

here are my correction / suggestions for bfct.lib (see in code as usual)

short summary:

1. it seems there are some bugs ... generate all examples and see!
   
2. due to splitting of functionality between different libs
   

some procs fail: e.g. bfctonestep needs `initialidealengine

3. wrong proc. names.
   

[Oleksandr]

my corrections / suggestions for bfct.lib

[Oleksandr]

Bad name: maybe "bsato.lib"?

[Oleksandr]

new version is called "bfun.lib" now

[Oleksandr]

Inspecting my changes/sugestions vs latest author's version

[Oleksandr]

Issues/suggestions (shortly):

1. All bfct* functions are which described as "compute

the Bernstein-Sato polynomial of f" actually return its roots+multiplicities. It happed in my test that that polynomial was zero, thus returned zero root with zero multiplicity, which does not exactly correspont to zero...

As far as i can see, you compute the polynomial and then, finally, factorize it... It seems so me that you might simply return the polynomial, or is there something bad with it?

2. some custom groebner-like gb-engines are employed in

bfun.lib/dmod.lib/dmodapp.lib/freegb.lib and one uses optional arguments to controll them. Sometimes even two such arguments: bfctSyz!

I personally think that *engine* - optional options look very messy and are damn hard to maintain / keep them in sync everywhere etc.

Therefore, please let me ask you to consider using procedure-attributes instead. I think this might turn out to be much more clearer and easier to maintain.

In fact, some of those custom-made gb-engines change options, which can be considered as a bug!

Moreover, as far as i know, one can set default "gb-engine" for groebner now! Is there still any reason not to use it?

Pease let me remind you some about the following:

3. There seems to be no explanation for b-function of an ideal:

bfctIdeal(I,w[,s,t]); computes the global b-function of ideal I w.r.t. the weight w

4. linSyzSolve still has the same bug (ring variable name-confict)

Besides, after looking a bit deeply into bfun.lib i noticed that:

5. all bfct* procedures does not check the assumption on the basering,

and moreover cannot generally work (due to linReduce*/initialMalgrange/initialIdealEngine) in several cases if there are parameters or the base ring is commutative G-algebra (nc_algebra(1,0)) and can easily crash Singular there...

Moreover there are problems with qrings since they are not supported by slimgb!!!! This seems to be another argument for using the standard "groebner" command!? Otherwise one might end up with three optional gb-engine-switches meaning the same, and so on... :)

[Oleksandr]

my tests for bfun.lib

[Oleksandr]

It seems that the example for pIntersectSyz have simply too much debug info, which should not be present on default printlevel...

[levandov]

many changes have been already made, now we analyze the tests by Alex.
now there is only one engine for using different Groebner routines.
NO qring, NO positive characteristic apply here in general, since there is no theory (and no interest yet) for these cases.

[levandov]

Mix of answers: Daniel Andres + Viktor Levandovskyy

Issues/suggestions (shortly):

1. All bfct* functions are which described as "compute the

Bernstein-Sato polynomial of f" actually return its roots+multiplicities. It happed in my test that that polynomial was zero, thus returned zero root with zero multiplicity, which does not exactly correspont to zero...

For proper input (poly not zero, or for bfctIdeal a holonomic ideal), the result cannot be 0 (see added theory in the header).

As far as i can see, you compute the polynomial and then, finally, factorize it... It seems so me that you might simply return the polynomial, or is there something bad with it?

For all bfct* procs (except bfctIdeal) the poly will have rational roots only. For constant input and for bfctIdeal, we return now a list with a third entry consisting of the product of all irreducible factors of degree not one (if such are given), see new proc bFactor in dmodapp.lib.

2. some custom groebner-like gb-engines are employed in

bfun.lib/dmod.lib/dmodapp.lib/freegb.lib and one uses optional arguments to controll them. Sometimes even two such arguments: bfctSyz!

I personally think that *engine* - optional options look very messy and are damn hard to maintain / keep them in sync everywhere etc.

Therefore, please let me ask you to consider using procedure-attributes instead. I think this might turn out to be much more clearer and easier to maintain.

In fact, some of those custom-made gb-engines change options, which can be considered as a bug!

Moreover, as far as i know, one can set default "gb-engine" for groebner now! Is there still any reason not to use it?

Thanks for the hint. Viktor has already written details in the track system. Recall: from now on there is just one procedure 'engine' with the same meaning for all the libs.

3. There seems to be no explanation for b-function of an ideal:

bfctIdeal(I,w[,s,t]); computes the global b-function of ideal I w.r.t. the weight w

Theory added to description of library.

4. linSyzSolve still has the same bug (ring variable name-confict)

Thanks, now it's fixed.

5. all bfct* procedures does not check the assumption on the basering,

and moreover cannot generally work (due to linReduce*/initialMalgrange/initialIdealEngine) in several cases if there are parameters or the base ring is commutative G-algebra (nc_algebra(1,0)) and can easily crash Singular there...

Assumption checks added. All parameter/nc_algebra(1,0) issues fixed.

Moreover there are problems with qrings since they are not supported by slimgb!!!! This seems to be another argument for using the standard "groebner" command!? Otherwise one might end up with three optional gb-engine-switches meaning the same, and so on... :)

Fixed. qrings are not meant to be supported. If procedures are called from qring, we prompt that we discard the quotient and proceed.

[levandov]

It seems that every issue has been fixed, all the tests are running good.