On 09/18/2017 12:33 PM, oldk1331 wrote:
> totalDegree:
>
> https://github.com/fricas/fricas/blob/master/src/algebra/gdpoly.spad#L43
Oh. Thanks. In on my working branch, I have removed exactly that
function. Funny. Everything still compiles without it.
totalDegree p ==
zero? p => 0
"max"/[reduce("+",(t.k)::(Vector NNI), 0) for t in p]
This implementation is a default and thus cannot be very efficient, but
it's problematic not only for the allocation of vectors and a list
(before "max" can run over it). For degree-compatible term orders there
is no need to consider anything more than the leading term. That must
have highest total degree by definition.
> DirectProductCategory, it only has IndexedAggregate, which doesn't
> has 'reduce':
>
> https://github.com/fricas/fricas/blob/master/src/algebra/vector.spad#L259
>
> I'm considering 2 choices:
> 1. add 'reduce' to DirectProductCategory
> 2. make a new category for fixed length aggregate.
> Such aggregate has unique properties, for example,
> there's no empty(), filter, etc.
No time to go into details about this, but I've the feeling it touches a
discussion about my suggestion of totalDegree in my poly branch.
https://github.com/hemmecke/fricas/commits/poly
I have not pushed further on this, because after the discussion with
Waldek and a few more thoughts, it didn't yet feel completely right to
generalise the groebner package without variable names in the way I did
it. In particular, I felt unhappy with the line
https://github.com/hemmecke/fricas/blob/poly/src/algebra/poly.spad#L74
if S has with (coerce: S -> Vector NonNegativeInteger) then
In that place S stands for the domain of the exponents. Why should I
require such a generic domain to be able to coerce to a vector. All I
need in that place and later for virtualDegree in Groebner computations
is a (non-negative) number, so it might be more sensible to have
something like
if S has with {grade: S -> NonNegativeInteger} then ...
But I haven't yet fully thought about whether that would be soo much
better. In terms of shifting the "totalDegree" computation (or at least
on a monomial) it would, because then DirectProduct(dim, NNI) would have
to export a function grade: % -> NNI, which is easy to implement.
So it's not yet the end of the day.
Ralf
--
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.
