Ralf Hemmecke wrote"
>
> > However one remark: ATM handling of DirectProduct(#vl, ...)
> > in Spad compiler is buggy, in particular the compiler rejects
> > valid code.
>
> Well, as I said. I would never design such code. The actually offending
> place for me is not at the place that was fixed by my patch but rather
> it is
>
> https://github.com/hemmecke/fricas-svn/blob/master/src/algebra/gdpoly.spad.pamphlet#L37
>
> GeneralDistributedMultivariatePolynomial(vl,R,E): public == private where
> vl: List Symbol
> R: Ring
> E: DirectProductCategory(#vl,NonNegativeInteger)
>
> and also
>
> DistributedMultivariatePolynomial(vl,R): public == private where
> vl : List Symbol
> R : Ring
> E ==> DirectProduct(#vl,NonNegativeInteger)
>
>
> If I had to design this, then I would certainly remove vl from the
> argument and just require E. E then may or may not provide names for the
> variables. In fact, polynomials would just be a monoid ring RE (ring R,
> monoid E) where E happens to have a particular structure that enables to
> extract variables and what not.
I am not sure if I would design polynomials as they are now. But
I am affraid what you propose just shifts problem to other place: there
are variables and we need DirectProduct of size matching number
of variables. As long as we want to have separate DirectProduct
and reuse it for exponents at some moment we need to match
size of the product with number of variables. We can request
that sizes are provided separately, but then either it will
be completely unchecked or we need special code in domain
to check at runtime. Alternatively, we could create
DirectProductWithVariableNames and pass vl as argument to
it instead of size. All the above IMHO is very inelegant.
Also, note that that for users it would be quite inconvenient
to specify E and you would need a wrapper domain which take
variables and produces E.
Actually I would think of change in opposite direction. Currently
we have:
PolynomialCategory(R:Ring, E:OrderedAbelianMonoidSup, VarSet:OrderedSet):
Category ==
...
However E is determined by the domain, so we could add 'exponentMonoid'
to polynomial domains and have someting like:
PolynomialWithExponentsCategory(R:Ring, E:OrderedAbelianMonoidSup,
VarSet:OrderedSet): Category ==
PolynomialCategory(R:Ring, VarSet:OrderedSet) : Category == _
PolynomialWithExponentsCategory(R, exponentMonoid()$%, VarSet) with
exponentMonoid : () -> OrderedAbelianMonoidSup
That way users of polynomials would be spared most of effort of
computing correct E (since given someting of PolynomialCategory
they could retrive it from the domain).
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
