> GroebnerPackage. So your patch is fine, but somehow at the wrong place. > Or rather it must be made conditional > > if R has CancellationAbelianMonoid then > if R has OrderedAbelianMonoidSup then
Your suggestion is correct. A bigger concern is, to avoid unnecessarily alloc memory, I do the '<' or 'subtractIfCan' computation twice. I wonder if it's a good tradeoff in general. It is good tradeoff in this case. > In fact, for the most common Groebner computations R is NNI, so I guess, > it even makes sense to have specialized code for it. So then Yes, for NNI to specialized so that it can be inlined. > map(subtractIfCan2$R, u, v) simply becomes something like u-v. There's no u-v for NNI, there's no 'subtract' as you suggested, so I use 'subtractIfCan2'. (bad name, I know) > There are a few places in gbintern.spad where it simply says > > subtractIfCan(a, b) :: Expon I noticed that too, so I suggest to add 'subtractIfCan2' for CancellationAbelianMonoid, with signature (%,%)->%, one should only use it when one can make sure it will success, for example, z=sup(x,y);subtractIfCan2(z,x). About the name, I think 'subtractCan' is better? > That's fine in mathematically, but in Vector I don't see that > specialised. In other words each subtraction of two vectors allocates 2 > new arrays, where one would certainly be enough. I agree. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
