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:
- it seems there are some bugs ... generate all examples and see!
- due to splitting of functionality between different libs
some procs fail: e.g. bfctonestep needs `initialidealengine
- wrong proc. names.
Attachments (3)
Change History (14)
Changed 14 years ago by
comment:1 Changed 14 years ago by
Cc: | levandov added; greuel removed |
---|---|
Summary: | corrections to bcft.lib → corrections to bfct.lib |
Bad name: maybe "bsato.lib"?
comment:2 Changed 14 years ago by
Owner: | changed from levandov to Oleksandr |
---|
comment:3 Changed 14 years ago by
Status: | new → assigned |
---|
comment:4 Changed 14 years ago by
Summary: | corrections to bfct.lib → corrections/review of bfct.lib |
---|
Changed 14 years ago by
Attachment: | bfun.lib.diff2 added |
---|
Inspecting my changes/sugestions vs latest author's version
comment:6 Changed 14 years ago by
Issues/suggestions (shortly):
- 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?
- 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:
- 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
- linSyzSolve still has the same bug (ring variable name-confict)
Besides, after looking a bit deeply into bfun.lib i noticed that:
- 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... :)
comment:7 Changed 14 years ago by
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
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
Owner: | changed from Oleksandr to levandov |
---|---|
Status: | assigned → new |
comment:10 Changed 14 years ago by
Status: | new → assigned |
---|
Mix of answers: Daniel Andres + Viktor Levandovskyy
Issues/suggestions (shortly):
- 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.
- 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.
- 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.
- linSyzSolve still has the same bug (ring variable name-confict)
Thanks, now it's fixed.
- 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
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
It seems that every issue has been fixed, all the tests are running good.
my corrections / suggestions for bfct.lib