Dear Simon,
On Sep 5, 12:34 pm, Simon King <simon.k...@nuigalway.ie> wrote:
> On Sep 5, 10:53 am, Oleksandr <mot...@rhrk.uni-kl.de> wrote:
> > First of all, please, let me explain that Singular kernel doesn't have
> > any such markers...
> Really? The only part of the Singular kernel that I ever met is
> iparith.cc, or is this not kernel? Here, one typically sees lines such as
> {jjSTD_HILB_WP, STD_CMD, IDEAL_CMD, 4
> NO_PLURAL}
> {jjREDUCE5, REDUCE_CMD, IDEAL_CMD/*or set by p*/, 5
> ALLOW_PLURAL}
> By "markers", I was referring to these NO_PLURAL / ALLOW_PLURAL
> markers.
Yes exactly - this is a part of Singular interpreter. Functions like
jjSTD_HILB_WP should (ideally) _only_ delegate the call to the
appropriate
kernel function (say kStd) while doing some interpreter-related checks
and
convert interpreter's data structures (e.g. leftv, attributes) into
something
kernel-understandable (e.g. poly/ideal/intvec).
> > I would propose to move these checks into kernel feature
> > implementations so that they can be done in run time by every
> > individual feature, [...]
> Perhaps it was my misunderstanding that iparith.cc is in the kernel.
I agree that at the moment the boundary between the Singular
interpreter
(which is the /Singular directory) and the kernel (/kernel) is a way
tooooo weak:
ideally there should be NO parts of singular kernel logic inside
interpreter wrappers (jj***)...
> I would agree that it makes mathematically sense to let each function
> check by itself whether the input is suitable (e.g.,
> checks whether we are in a graded commutative weighted homogeneous
> setting, in which Hilbert driven standard basis computation makes
> sense).
> However, I am not sure if Hans or Gert-Martin would agree that it
> makes practically sense. After all, testing for complicated conditions
> under which a function works costs time.
> So, why not have a very simple test (commutative vs. non-commutative) that is
> immediate?
Well, this "simple test" is exactly the existing static NO_PLURAL/
ALLOW_PLURAL-marker functionality.
Specific tests (detections) are performed _once_ during the algebra
construction.
Afterwards checks like "is non-commutative" or "is supercommutative"
are _cheap_
(see rIsPluralRing and rIsSCA).
> Therefore my suggestion to have markers, say ALLOW_G_ALGEBRA,
> ALLOW_SC_ALGEBRA, NO_PLURAL.
You see, the idea was to provide a framework in which one can easily
implement
any particular GR-algebra as a separate kernel extension with its own
multiplication routines and SB-related algorithms in a virtual-
overloading manner.
At the moment SCA is just an example of how this can be done...
Moreover, we already have a separate experimental implementation where
multiplication
uses formulas for specific automatically detectable G-algebras (e.g.
Weyl) instead of raw
relations+caching (as in the general G-algebra). I guess these
formulas will eventually be
merged into the framework...
More importantly: if Sage accesses the Singular kernel directly -
these Singular interpreter markers cannot help Sage...
Regards,
Oleksandr
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
