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.
It's not that I consider the above code invalid, I just don't like that
the return type of DMP not only depends on vl but on a function applied
to vl.
I am a bit surprised that the new version compiles,
As you see in the patch there was even a comment that some code would
not compile without the nv parameter.
BTW, rejecting valid code like DirectProduct(#vl, ...) in some
context I consider as probably worst currently unfixed bug
in Spad compiler.
Well, maybe. But since I don't like such code anyway, I don't care too much.
Ralf
--
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.
