Ralf Hemmecke wrote:
>
> I cannot easily send all the code, because it is a bit long.
> Maybe you can still give me a hint how to go on from here and perhaps to
> find to real cause of the problem.
>
> The compilation ends in the output below. That only seems to indicate
> Warnings, but executing the function, shows that there is a true problem.
>
> (8) -> Z ==> Integer
> Type:
> Void
> (9) -> Q ==> Fraction Z
> Type:
> Void
> (11) -> QEW ==> QEtaWork Q
> Type:
> Void
> (12) -> etaQuotientRelations(6)$QEW
>
> >> System error:
> The function BOOT::|#| is undefined.
>
> I somehow believe that it has something to do with this piece of code...
>
>
> computeEtaQuotientRelations(
> dim: N, vl: List Symbol, witnesses: LLUP): LPol ==
>
> E ==> SplitHomogeneousDirectProduct(#vl, dim, N)
^^^
> R ==> GeneralDistributedMultivariatePolynomial(vl, C, E)
> OVL ==> OrderedVariableList(vl)
>
> ovl: List OVL := enumerate()$OVL
> vars := [x::R for x in ovl]
> ...
>
> in particular the connection between the vl in E and R.
> In fact, initially I passed #vl as argument to this function as a
> parameter dimx and used dimx instead of #vl in the definition of E.
> But then the compiler complained that the type of E did not match in R.
>
> Any ideas?
This looks like a bug with handling parametized types: basically
non-type parameters must be trivial for this to work correctly.
Actually I encountered this bug in very similar situation -- I
wanted to use Groebner bases with elimination ordering so
I tried SplitHomogeneousDirectProduct. Unfortunately, this
works in interpreter, but does not work in Spad compier.
More precisely, due to definition of
GeneralDistributedMultivariatePolynomial where we have:
E : DirectProductCategory(#vl, NonNegativeInteger)
and the way Spad typechecking works this works only when
SplitHomogeneousDirectProduct gets as the first argument
expression which after substitutuin for 'vl' gives the
same expression as substitutuin for 'vl' in '#vl'.
Unfortuantely, inside functions Spad compiler performs
transformations needed to get executable code, while
type declaration inside export part is stored as-is. The
effect is that I know of no way to use
GeneralDistributedMultivariatePolynomial with
SplitHomogeneousDirectProduct with variable
arguments from Spad code (fixed arguments should be OK
because they are represented by the same Lisp
expression).
--
Waldek Hebisch
--
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.
