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 -~----------~----~----~----~------~----~------~--~---