Templates and p_Procs...

[Benjamin Schnitzler]

Dear singular developement list,

I am trying to adapt the multiplication used in the original
singular bba to our version of the bba. (We are trying to compute
non-commutative Groebner bases with the Letterplace approach.)
Unfortunatly I do not yet completely understand, how the
multiplications in Singular are instantiated. I know, that there
are different ring and order dependent versions of
multiplications, which reside in libpolys/polys/templates .
My idea was to create our own multiplications based on those
(e.g. p_Minus_mm_Mult_qq__T) in the libpolys/polys/templates
directory, but they make use of other template functions (e.g.
n_Mult__T, n_Delete__T, ...), which I do not want to rewrite, but
simply to use in the usual manner. How do I get these templates
instantiated correctly?

Thank you,

Benjamin

[Oleksandr]

Hi, 

AFAIK, we have letterplace in Singular... although it works on top of commutative rings. 

What kind of NC rings do you need? 

Besides, the templates you mention are only for speeding up some popular commutative cases and usually one should not need to change them at all.

Cheers, 

Oleksandr

[Ben]

Hi,
thank you for your reply :) .
> Hi,f

>
> AFAIK, we have letterplace in Singular... although it works on top of
> commutative rings.

Yes, the idea of letterplace is to create a commutative ring with
elements corresponding to a non-commutative ring, to perform
commutative operations (e.g. GB calculations on Ideals) in it and to
use the correspondence to get an interpreation in the non-commutative
ring. We are currently working on replacing the old letterplace
version by
an improved version. We already implemented that for the homogenous
case. However: If the Ideal is not homogenous, multiplications are not
as
easyly accomplished (even in the homogenous case multiplications can
be improved). I can give you more infos and examples if you like to
have
them. The implementational Problem resides in the fact, that we can
not
just add exponent vectors, as it is possible, when using a non-
letterplace
ring. (This is due to the design of the exponent-vectors which didn't
have
to consider the letterplace ring, when it was invented.) So we need to
make
slight changes to the multiplications. In the former version of the
letterplace implementation, a trick was used to evade problems, but
unfortunatly performance was not very high. Now we might be able to
improve that (we already performed some tests), but the critical parts
of the code are the multiplications, which are realized as templates,
as
stated in my post from above.

> What kind of NC rings do you need?

It should now be clear, that I don't need NC rings.

>
> Besides, the templates you mention are only for speeding up some popular
> commutative cases and usually one should not need to change them at all.

Yes, I can understand, that this was thought to be true, when this
system
was invented. However: From my perspective, it could result in a
major
improvement, if we would change it now (or better: extend it, such
that it
will be useful for us).
>
> Cheers,
> Oleksandr

Greetings,
Benjamin

[Oleksandr Motsak]

Ok, looks like you are trying to improve our letterplace subsystem. It
would be best if you contact someone responsible for it, like Roberto
La Scala or Viktor Levandovskyy.

For a special multiplication: you just overload the multiplication
method (there is a function pointer for it).
But since the base letterplace ring is commutative there is only one
multiplication routine which is used for both a*b and b*a.

If you need to change that - just create a new (Plural) NC (almost
commutative) ring and overload both multiplication routines there.

Again, I would strongly discourage any changes to that old
macros-template stuff, which gonna be replaced by proper C++ templates
anyway.

Btw, would you be interested in working on such a replacement (which
is, frankly, quite a challenging task)?

Hope this helps,
Oleksandr

2012/9/7 Ben <benjamins...@googlemail.com>:

[Benjamin Schnitzler]

Hi!

On 15:26 Fri 07 Sep , Oleksandr Motsak wrote:
> Ok, looks like you are trying to improve our letterplace subsystem. It
> would be best if you contact someone responsible for it, like Roberto
> La Scala or Viktor Levandovskyy.

Yes, i already contacted Viktor Levandovskyy, we just had lunch
together. (To be more exact: I'm a student at the RWTH Aachen and
he's my boss. I maybe should have said that beforehand, sorry.)

> For a special multiplication: you just overload the multiplication
> method (there is a function pointer for it).
> But since the base letterplace ring is commutative there is only one
> multiplication routine which is used for both a*b and b*a.

I think there are several multiplication functions. Those which
seem to occeur in the bba are:
pp_Mult_mm__T
pp_Mult_mm_Noether__T
p_Minus_mm_Mult_qq__T

p_Minus_mm_Mult_qq__T for example is called by
sLObject::Tail_Minus_mm_Mult_qq, indeed as a function pointer. Of
course if I say p_Minus_mm_Mult_qq__T is called, that is
misleading, as p_Minus_mm_Mult_qq__T is just a template which was
constructed beforehand. This template construction is one thing i
do not yet understand; where do You store the constructed
templates? How does this work, or how should it work? if You are
talking about C++ templates. (Do You mean proper C++ Templates?)

The reason, why I want (or wanted) to know something about the
template system is, that I want to use most parts of the existing
multiplication functions. But just copying the templates (of
course) does not work.

> If you need to change that - just create a new (Plural) NC (almost
> commutative) ring and overload both multiplication routines there.

I talked with viktor about the nc structure/system. The idea is
quite good, but I do not want to rewrite the whole
multiplications for every ordering and every ring, instead I'd
like to make small changes to these functions for some orderings,
but leave the rest, as it is. See it like this: I would like to
create a new branch of these template functions, independent from
the old ones, to change some small bits of it.

> Again, I would strongly discourage any changes to that old
> macros-template stuff, which gonna be replaced by proper C++ templates
> anyway.
>
> Btw, would you be interested in working on such a replacement (which
> is, frankly, quite a challenging task)?

Yes, I could help You a bit. I haven't had to much opportunities
to work with C++ templates and it sounds interesting. What is
needed, as far, as I can see that, are templates with functions
or classes as parameters, but one has to think about that a bit
more in depth; how exactly do You plan to do that?
>
> Hope this helps,
> Oleksandr

[han...@mathematik.uni-kl.de]

On Fri, Sep 07, 2012 at 07:02:56PM +0200, Benjamin Schnitzler wrote:
> Hi!

> > For a special multiplication: you just overload the multiplication
> > method (there is a function pointer for it).
> > But since the base letterplace ring is commutative there is only one
> > multiplication routine which is used for both a*b and b*a.
> I think there are several multiplication functions. Those which
> seem to occeur in the bba are:
> pp_Mult_mm__T
> pp_Mult_mm_Noether__T
> p_Minus_mm_Mult_qq__T
>
> p_Minus_mm_Mult_qq__T for example is called by
> sLObject::Tail_Minus_mm_Mult_qq, indeed as a function pointer. Of
> course if I say p_Minus_mm_Mult_qq__T is called, that is
> misleading, as p_Minus_mm_Mult_qq__T is just a template which was
> constructed beforehand. This template construction is one thing i
> do not yet understand; where do You store the constructed
> templates? How does this work, or how should it work? if You are
> talking about C++ templates. (Do You mean proper C++ Templates?)

No, the routines for p_Procs are not C++-templtaes, as the C++-template
system is not flexible enough for that.
(for example, one cannot substitute a call by nothing, and
you cannot inline without the help of the optimizer, and
its all fixed at compile time, and...)
They are iplemented via function pointers for all these routines
(see p_Procs_Impl.h):
p_Copy
p_Delete
p_ShallowCopyDelete
p_Mult_nn
pp_Mult_nn
pp_Mult_mm
p_Mult_mm
p_Minus_mm_Mult_qq
pp_Mult_mm_Noether
p_Add_q
p_Neg
pp_Mult_Coeff_mm_DivSelect
pp_Mult_Coeff_mm_DivSelectMult
p_Merge_q
p_kBucketSetLm
For these function pointer p_Procs_Generate generates routines
of the form <routine>_<field>_<length of the monomial>_<order>
by producing the C++ code in p_Procs*.inc, which in turn used cpp
with <routine>_T.cc
THE NC subsystem works by resetting some of these function pointers after
they are set for a commutave ring.

>
> The reason, why I want (or wanted) to know something about the
> template system is, that I want to use most parts of the existing
> multiplication functions. But just copying the templates (of
> course) does not work.

If you want to generate more routines, change p_Procs_Generate.cc
to generate them, and SetProcs to set them.
(See HAVE_RINGS for an example)
Otherwise, it may be better to implement them independently
and later reset these pointers (see NC system).

>
> > If you need to change that - just create a new (Plural) NC (almost
> > commutative) ring and overload both multiplication routines there.
> I talked with viktor about the nc structure/system. The idea is
> quite good, but I do not want to rewrite the whole
> multiplications for every ordering and every ring, instead I'd
> like to make small changes to these functions for some orderings,
> but leave the rest, as it is. See it like this: I would like to
> create a new branch of these template functions, independent from
> the old ones, to change some small bits of it.
>
> > Again, I would strongly discourage any changes to that old
> > macros-template stuff, which gonna be replaced by proper C++ templates
> > anyway.
> >
> > Btw, would you be interested in working on such a replacement (which
> > is, frankly, quite a challenging task)?
> Yes, I could help You a bit. I haven't had to much opportunities
> to work with C++ templates and it sounds interesting. What is
> needed, as far, as I can see that, are templates with functions
> or classes as parameters, but one has to think about that a bit
> more in depth; how exactly do You plan to do that?

This is quite difficult, as we have to find a way between
inling everything (e.g. template instantiations for everything), which lead
to a large code size (bad for performance) and inlining nothing
(e.g. virtal/generic functions for everything), which is also bad.
Currently we inline Z/p and Q operations, and do loop unrolling
for some sizes of monomials and some types of orderings.
(And has some problems, as mentioned above)
> >
Hannes

[Oleksandr Motsak]

2012/9/7 <han...@mathematik.uni-kl.de>:

> On Fri, Sep 07, 2012 at 07:02:56PM +0200, Benjamin Schnitzler wrote:
>> I talked with viktor about the nc structure/system. The idea is
>> quite good, but I do not want to rewrite the whole
>> multiplications for every ordering and every ring, instead I'd

that's the whole point - simply reset needed function pointers by your
*generic* multiplication functions!
No need to deal with that old mess.

>> > Btw, would you be interested in working on such a replacement (which
>> > is, frankly, quite a challenging task)?
>> Yes, I could help You a bit. I haven't had to much opportunities
>> to work with C++ templates and it sounds interesting. What is
>> needed, as far, as I can see that, are templates with functions
>> or classes as parameters, but one has to think about that a bit
>> more in depth; how exactly do You plan to do that?
> This is quite difficult, as we have to find a way between
> inling everything (e.g. template instantiations for everything), which lead
> to a large code size (bad for performance) and inlining nothing
> (e.g. virtal/generic functions for everything), which is also bad.
> Currently we inline Z/p and Q operations, and do loop unrolling
> for some sizes of monomials and some types of orderings.
> (And has some problems, as mentioned above)

IMHO, the point is to generate *the same* code but in an *easily
extendable way*, e.g. using modern C++ templated meta-programming
(traits) -
using template specializations for needed coeff. domains (Q, Z/pZ,..),
orderings (dp,..) etc...

> (for example, one cannot substitute a call by nothing, and
> you cannot inline without the help of the optimizer,

nowadays there are almost no no-optimizing compilers (unless one
specifically ask for that),
additionally one can *force* inlining for the most popular ones (e.g.
__attribute__((always_inline)) in gcc and clang).

> and its all fixed at compile time,

but that's exactly what we have now (and need):
static instantiation (generation) of specialized functions (sources)
in compile time, no?

> and...
and?

Cheers,
Oleksandr

[Ben]

> Yes, i already contacted Viktor Levandovskyy, we just had lunch
> together. (To be more exact: I'm a student at the RWTH Aachen and
> he's my boss. I maybe should have said that beforehand, sorry.)

I should have mentioned the fact, that Grischa Studzinski is working
together with me on that projekt.

[Benjamin Schnitzler]

> If you want to generate more routines, change p_Procs_Generate.cc
> to generate them, and SetProcs to set them.
> (See HAVE_RINGS for an example)
> Otherwise, it may be better to implement them independently
> and later reset these pointers (see NC system).

Thank You, I think that is the information, I needed!

[Benjamin Schnitzler]

On 20:28 Fri 07 Sep , Oleksandr Motsak wrote:
> 2012/9/7 <han...@mathematik.uni-kl.de>:
> > On Fri, Sep 07, 2012 at 07:02:56PM +0200, Benjamin Schnitzler wrote:
> >> I talked with viktor about the nc structure/system. The idea is
> >> quite good, but I do not want to rewrite the whole
> >> multiplications for every ordering and every ring, instead I'd
>
> that's the whole point - simply reset needed function pointers by your
> *generic* multiplication functions!
> No need to deal with that old mess.

I understand what You mean; again: The idea is good, but at the
current state of the Singular/Plural code it will not work. The
reason is: To implement our algorithm, we made use of the
Singular code; we adapted it to our needs (to do it like this was
a demand of viktor and it makes sense, because rewriting all the
code may have taken a significant bigger amount of time). I will
give You a concrete example: The p_Minus_mm_Mult_qq__T (template)
function is used (indirectly) by ksCreateSpoly. We do not want to
rewrite this function completely, so we can not just change a
pointer, to overwrite it (and by the way, this kind of function
is not present in the nc/p_procs system), but yet, we want to
change *parts* of this function (for example we cannot make use
of existing p_MemSum__T implementations: we have to replace this!).
I will now try to adapt the template generation file Hannes
mentioned, maybe this leads to right direction.

> >> > Btw, would you be interested in working on such a replacement (which
> >> > is, frankly, quite a challenging task)?
> >> Yes, I could help You a bit. I haven't had to much opportunities
> >> to work with C++ templates and it sounds interesting. What is
> >> needed, as far, as I can see that, are templates with functions
> >> or classes as parameters, but one has to think about that a bit
> >> more in depth; how exactly do You plan to do that?
> > This is quite difficult, as we have to find a way between
> > inling everything (e.g. template instantiations for everything), which lead
> > to a large code size (bad for performance) and inlining nothing
> > (e.g. virtal/generic functions for everything), which is also bad.

That seems to me a problem which concerns the template
generation in general - not only this of (proper) C++ templates.

> > Currently we inline Z/p and Q operations, and do loop unrolling
> > for some sizes of monomials and some types of orderings.
> > (And has some problems, as mentioned above)
>
> IMHO, the point is to generate *the same* code but in an *easily
> extendable way*, e.g. using modern C++ templated meta-programming
> (traits) -

The code would also become more uniform and closer to standard.
This all would make it easier to maintain and easier to
understand for those who do not now to much about the singular
internals.

> using template specializations for needed coeff. domains (Q, Z/pZ,..),
> orderings (dp,..) etc...
>
> > (for example, one cannot substitute a call by nothing, and
> > you cannot inline without the help of the optimizer,
>
> nowadays there are almost no no-optimizing compilers (unless one
> specifically ask for that),
> additionally one can *force* inlining for the most popular ones (e.g.
> __attribute__((always_inline)) in gcc and clang).

So to substitute a call by nothing one would create an empty
dummy function and wait for the compiler to optimize it to zero?
Does that work?
Is there something similar to the __attribute__((always_inline))
keyword for other popular compilers? And I guess one has to be
careful with this statement, as it will prevent compiler
optimization?

[Oleksandr Motsak]

2012/9/8 Benjamin Schnitzler <benjamins...@googlemail.com>:

> On 20:28 Fri 07 Sep , Oleksandr Motsak wrote:
>> 2012/9/7 <han...@mathematik.uni-kl.de>:
>> > On Fri, Sep 07, 2012 at 07:02:56PM +0200, Benjamin Schnitzler wrote:
>> >> I talked with viktor about the nc structure/system. The idea is
>> >> quite good, but I do not want to rewrite the whole
>> >> multiplications for every ordering and every ring, instead I'd
>>
>> that's the whole point - simply reset needed function pointers by your
>> *generic* multiplication functions!
>> No need to deal with that old mess.

> I understand what You mean; again: The idea is good, but at the
> current state of the Singular/Plural code it will not work. The

It will certainly work provided you may also extend Plural while
obeying to our conventions and rules.
Whereas if you hack internals too much (e.g. change templates) - you
risk that your contributions may never be accepted to mainstream.

> reason is: To implement our algorithm, we made use of the
> Singular code; we adapted it to our needs (to do it like this was
> a demand of viktor and it makes sense, because rewriting all the
> code may have taken a significant bigger amount of time). I will
> give You a concrete example: The p_Minus_mm_Mult_qq__T (template)
> function is used (indirectly) by ksCreateSpoly. We do not want to
> rewrite this function completely, so we can not just change a
> pointer, to overwrite it (and by the way, this kind of function
> is not present in the nc/p_procs system), but yet, we want to
> change *parts* of this function (for example we cannot make use

AFAIK, nobody should directly call p_Procs->p_Minus_mm_Mult_qq (save
for p_Minus/Plus_mm_Mult_qq),
so we should fix that and probably also set it directly to something
like nc_p_Minus_mm_Mult_qq.
Hans, what do you think on this matter?

Moreover p_Minus/Plus_mm_Mult_qq are supposed to call
nc_p_Minus_mm_Mult_qq (it's a bug otherwise),
which is a generic function (since there was no need to make it templated).
Therefore the proper way for you would be to change
nc_p_Minus_mm_Mult_qq instead.

> of existing p_MemSum__T implementations: we have to replace this!).

Of course one is to use p_ExpVectorSum or p_MemSum_LengthGeneral instead.

> I will now try to adapt the template generation file Hannes
> mentioned, maybe this leads to right direction.

If you see any reasons against the canonical approach (i.e. extending Plural) -
please let us know and i hope that we will be able to advise you
against that hackery and waisting your time.

>> IMHO, the point is to generate *the same* code but in an *easily
>> extendable way*, e.g. using modern C++ templated meta-programming
>> (traits) -
> The code would also become more uniform and closer to standard.
> This all would make it easier to maintain and easier to
> understand for those who do not now to much about the singular
> internals.

yeah, that's the intention.

>> nowadays there are almost no no-optimizing compilers (unless one
>> specifically ask for that),
>> additionally one can *force* inlining for the most popular ones (e.g.
>> __attribute__((always_inline)) in gcc and clang).
> So to substitute a call by nothing one would create an empty
> dummy function and wait for the compiler to optimize it to zero?
> Does that work?

yep

> Is there something similar to the __attribute__((always_inline))
> keyword for other popular compilers?

yeah (usually using #pragma's)

> And I guess one has to be careful with this statement, as it will prevent compiler
> optimization?

Sorry, but i don't see how exactly forcing an individual *stub*
function inlining can prevent optimization?

O.

[Benjamin Schnitzler]

On 18:18 Sun 09 Sep , Oleksandr Motsak wrote:
> 2012/9/8 Benjamin Schnitzler <benjamins...@googlemail.com>:
> > On 20:28 Fri 07 Sep , Oleksandr Motsak wrote:
> >> 2012/9/7 <han...@mathematik.uni-kl.de>:
> >> > On Fri, Sep 07, 2012 at 07:02:56PM +0200, Benjamin Schnitzler wrote:
> >> >> I talked with viktor about the nc structure/system. The idea is
> >> >> quite good, but I do not want to rewrite the whole
> >> >> multiplications for every ordering and every ring, instead I'd
> >>
> >> that's the whole point - simply reset needed function pointers by your
> >> *generic* multiplication functions!
> >> No need to deal with that old mess.
>
> > I understand what You mean; again: The idea is good, but at the
> > current state of the Singular/Plural code it will not work. The
>
> It will certainly work provided you may also extend Plural while
> obeying to our conventions and rules.
> Whereas if you hack internals too much (e.g. change templates) - you
> risk that your contributions may never be accepted to mainstream.

May be so, but yet I do not know understand, how avoid rewriting
all the multiplications, without adapting the functions at the
right places. If the template system is not meant to be
extendable, or adaptable, then this is a problematic piece of the
singular code, which is one thing, why I agree with You, that it
should be rewritten using proper C++ templates. If Hannes is
sceptic, I can understand that, for sure there was lots of work
put into the template system.

>
>
> > reason is: To implement our algorithm, we made use of the
> > Singular code; we adapted it to our needs (to do it like this was
> > a demand of viktor and it makes sense, because rewriting all the
> > code may have taken a significant bigger amount of time). I will
> > give You a concrete example: The p_Minus_mm_Mult_qq__T (template)
> > function is used (indirectly) by ksCreateSpoly. We do not want to
> > rewrite this function completely, so we can not just change a
> > pointer, to overwrite it (and by the way, this kind of function
> > is not present in the nc/p_procs system), but yet, we want to
> > change *parts* of this function (for example we cannot make use
>
> AFAIK, nobody should directly call p_Procs->p_Minus_mm_Mult_qq (save
> for p_Minus/Plus_mm_Mult_qq),
> so we should fix that and probably also set it directly to something
> like nc_p_Minus_mm_Mult_qq.
> Hans, what do you think on this matter?

As I said, it its called indirectly. To be more exact:
ksCreateSpoly calls LObject::Tail_Minus_mm_Mult_qq, which then
calls r->p_Procs->p_Minus_mm_Mult_qq . Doesn't make a difference
for me.

>
> Moreover p_Minus/Plus_mm_Mult_qq are supposed to call
> nc_p_Minus_mm_Mult_qq (it's a bug otherwise),
> which is a generic function (since there was no need to make it templated).
> Therefore the proper way for you would be to change
> nc_p_Minus_mm_Mult_qq instead.
>
> > of existing p_MemSum__T implementations: we have to replace this!).
>
> Of course one is to use p_ExpVectorSum or p_MemSum_LengthGeneral instead.
>
> > I will now try to adapt the template generation file Hannes
> > mentioned, maybe this leads to right direction.
>
> If you see any reasons against the canonical approach (i.e. extending Plural) -
> please let us know and i hope that we will be able to advise you
> against that hackery and waisting your time.

I did not make a final decision yet. Extending Plural seems to be
a good thing, but I can yet not see, how this will help me in my
current situation, which I did explain above. I am also a bit
confused about what Plural is supposed to be. As far as I
understand it, it is (partially) a wrapper around the other
singular code, which allows to set some generic functions and
settings. However: If one (if I) wants to change only parts of
the existing (template) functions, rather than to rewrite them,
this is not the solution. I have also to talk back to Viktor. If
I really have to rewrite those functions, it might much slow down
the progress of our project. We would really have to write new
functions for every ring and ordering, which would be done by
just looking, what the template system does and copying that to
our own code files, which is something I really think to be
rather inefficient... But I do not yet have an overview over all
those cases I have to consider.

> > And I guess one has to be careful with this statement, as it will prevent compiler
> > optimization?
>
> Sorry, but i don't see how exactly forcing an individual *stub*
> function inlining can prevent optimization?

Yes, I think I just misunderstood You. I thought, You wanted
to use theese inlines also for other functions than these stub
functions.

[Oleksandr Motsak]

2012/9/9 Benjamin Schnitzler <benjamins...@googlemail.com>:

> On 18:18 Sun 09 Sep , Oleksandr Motsak wrote:
>> It will certainly work provided you may also extend Plural while
>> obeying to our conventions and rules.
>> Whereas if you hack internals too much (e.g. change templates) - you
>> risk that your contributions may never be accepted to mainstream.

> May be so, but yet I do not know understand, how avoid rewriting
> all the multiplications, without adapting the functions at the
> right places.

Well, instead of "adapting functions at the right places" (which means
hacking Singular internals)
one should simply write *generic* multiplication routines (4 of them:
p*mm/pp*mm and mm*p/mm*pp),
which are to be used instead.

Please do take a look at some simple Plural ring implementation (e.g.
SCA at libpolys/polys/nc/sca.cc in Spielwiese Singular).

BTW, please do use spielwiese Singular instead of the `master` branch
(see also https://github.com/Singular/Sources/wiki).

> If the template system is not meant to be
> extendable, or adaptable, then this is a problematic piece of the
> singular code, which is one thing, why I agree with You, that it
> should be rewritten using proper C++ templates. If Hannes is
> sceptic, I can understand that, for sure there was lots of work
> put into the template system.

Yep, it kinda works but is too outdated as it is difficult and tricky
to extend and adapt.
IMHO, modern C++ compilers can do the same job (e.g. via C++ Template
metaprogramming,
see http://en.wikipedia.org/wiki/Template_metaprogramming)
in much more extendable and adaptable way.

>> AFAIK, nobody should directly call p_Procs->p_Minus_mm_Mult_qq (save
>> for p_Minus/Plus_mm_Mult_qq),
>> so we should fix that and probably also set it directly to something
>> like nc_p_Minus_mm_Mult_qq.
>> Hans, what do you think on this matter?

> As I said, it its called indirectly. To be more exact:
> ksCreateSpoly calls LObject::Tail_Minus_mm_Mult_qq, which then
> calls r->p_Procs->p_Minus_mm_Mult_qq . Doesn't make a difference
> for me.

As I said, this seems to be an issue since it would fail for any NC ring
and thus has to be changed to call p_Minus_mm_Mult_qq instead.
In turn, p_Minus_mm_Mult_qq calls nc_p_Minus_mm_Mult_qq for NC rings.

>> If you see any reasons against the canonical approach (i.e. extending Plural) -
>> please let us know and i hope that we will be able to advise you
>> against that hackery and waisting your time.

> I did not make a final decision yet. Extending Plural seems to be
> a good thing, but I can yet not see, how this will help me in my
> current situation, which I did explain above. I am also a bit
> confused about what Plural is supposed to be. As far as I
> understand it, it is (partially) a wrapper around the other
> singular code, which allows to set some generic functions and
> settings.

Basically yes, a set of hooks/wrappers is used in order to
make it possible to overload non-commutative polynomial arithmetic
for individual NC rings.

> However: If one (if I) wants to change only parts of
> the existing (template) functions, rather than to rewrite them,
> this is not the solution.
> I have also to talk back to Viktor. If
> I really have to rewrite those functions, it might much slow down
> the progress of our project.
> We would really have to write new functions for every ring and ordering, which would be done by

Why? IMHO, nobody is supposed to do that!
As Plural has nothing to do with those *commutative* templated
functions (and they are supposed to stay that way),
one simply writes one or two *generic* multiplication functions
(without any compile time optimizations for any popular settings)
which are supposed to be able to work generically with any coeff.
domain / any number of variables / any ring ordering.

Note that those templated functions *only* exist for the purpose of
*optimization* for some popular commutative rings. And nothing else!

I really think that this is the only realistic way for you as changing
those templated functions will NOT do the trick for you as they are
supposed to be *commutative* by Singular design (e.g. there is a
single term multiplication which gets called for computing both a*b
and b*a alike in many places, which is also the reason why we needed
some more additional hooks for NC rings).

> just looking, what the template system does and copying that to
> our own code files, which is something I really think to be
> rather inefficient... But I do not yet have an overview over all
> those cases I have to consider.

please see above.

O.