Opened 14 years ago

Closed 14 years ago

#55 closed task (fixed)

corrections/review of bfct.lib

Reported by: Oleksandr Owned by: levandov
Priority: major Milestone: Release 3-1-0
Component: singular-libs Version:
Keywords: Cc: levandov, greuel, Oleksandr

Description

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

  1. wrong proc. names.

Attachments (3)

bfct.lib (38.7 KB) - added by Oleksandr 14 years ago.
my corrections / suggestions for bfct.lib
bfun.lib.diff2 (38.0 KB) - added by Oleksandr 14 years ago.
Inspecting my changes/sugestions vs latest author's version
bfun.tst (8.4 KB) - added by Oleksandr 14 years ago.
my tests for bfun.lib

Download all attachments as: .zip

Change History (14)

Changed 14 years ago by Oleksandr

Attachment: bfct.lib added

my corrections / suggestions for bfct.lib

comment:1 Changed 14 years ago by Oleksandr

Cc: levandov added; greuel removed
Summary: corrections to bcft.libcorrections to bfct.lib

Bad name: maybe "bsato.lib"?

comment:2 Changed 14 years ago by Oleksandr

Owner: changed from levandov to Oleksandr

comment:3 Changed 14 years ago by Oleksandr

Status: newassigned

comment:4 Changed 14 years ago by Oleksandr

Summary: corrections to bfct.libcorrections/review of bfct.lib

comment:5 Changed 14 years ago by Oleksandr

Cc: levandov removed

new version is called "bfun.lib" now

Changed 14 years ago by Oleksandr

Attachment: bfun.lib.diff2 added

Inspecting my changes/sugestions vs latest author's version

comment:6 Changed 14 years ago by 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?

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

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

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

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

  1. 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... :)

Changed 14 years ago by Oleksandr

Attachment: bfun.tst added

my tests for bfun.lib

comment:7 Changed 14 years ago by Oleksandr

Cc: levandov added

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

comment:8 Changed 14 years ago by levandov

Cc: greuel Oleksandr added

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.

comment:9 Changed 14 years ago by Oleksandr

Owner: changed from Oleksandr to levandov
Status: assignednew

comment:10 Changed 14 years ago by levandov

Status: newassigned

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.

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

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

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

Thanks, now it's fixed.

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

comment:11 Changed 14 years ago by levandov

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.