"Bill Page" <[EMAIL PROTECTED]> writes:
> What sort of problem would you forsee? It seems to me that it should
> suffice. E.g.
...
> ---------
>
> But it does raise the question about when (or if) explicit coercions need to
> be generated in InputForm. Presumably the goal is always to be able to
> generate an InputForm which when interpreted would generate the original,
> i.e.
>
> interpret(x::InputForm) = x
>
> for all (or at least a large subset) of values x of (almost all) types. Are
> there examples of values which cannot be expressed without coercions?
I remember problems when I hacked together SSOLVE. For your convenience, below
is the relevant part. It would be good to make the problems explicit, so that
we have something for the testsuite...
However, I should admit that I do not know whether the problems in seriesSolve
have anything to do with INFORM.
Martin
<<package EXPRSOL ExpressionSolve>>=
)abb package EXPRSOL ExpressionSolve
ExpressionSolve(R, F, UTSF, UTSSUPF): Exports == Implementation where
R: Join(OrderedSet, IntegralDomain, ConvertibleTo InputForm)
F: FunctionSpace R
UTSF: UnivariateTaylorSeriesCategory F
SUP ==> SparseUnivariatePolynomialExpressions
UTSSUPF: UnivariateTaylorSeriesCategory SUP F
OP ==> BasicOperator
SY ==> Symbol
NNI ==> NonNegativeInteger
MKF ==> MakeBinaryCompiledFunction(F, UTSSUPF, UTSSUPF, UTSSUPF)
Exports == with
seriesSolve: (F, OP, SY, List F) -> UTSF
replaceDiffs: (F, OP, Symbol) -> F
Implementation == add
<<implementation: EXPRSOL ExpressionSolve>>
@
The general method is to transform the given expression into a form which can
then be compiled. There is currently no other way in Axiom to transform an
expression into a function.
We need to replace the differentiation operator by the corresponding function
in the power series category, and make composition explicit. Furthermore, we
need to replace the variable by the corresponding variable in the power series.
It turns out that the compiler doesn't find the right definition of
[[monomial(1,1)]]. Thus we introduce it as a second argument. In fact, maybe
that's even cleaner. Also, we need to tell the compiler that kernels that are
independent of the main variable should be coerced to elements of the
coefficient ring, since it will complain otherwise.
\begin{ToDo}
I cannot find an example for this behaviour right now. However, if I do use
the coerce, the following fails:
\begin{verbatim}
seriesSolve(h x -1-x*h x *h(q*x), h, x, [1])
\end{verbatim}
\end{ToDo}
<<implementation: EXPRSOL ExpressionSolve>>=
opelt := operator("elt"::Symbol)$OP
opdiff := operator("D"::Symbol)$OP
opcoerce := operator("coerce"::Symbol)$OP
-- replaceDiffs: (F, OP, Symbol) -> F
replaceDiffs (expr, op, sy) ==
lk := kernels expr
for k in lk repeat
-- if freeOf?(coerce k, sy) then
-- expr := subst(expr, [k], [opcoerce [coerce k]])
if is?(k, op) then
arg := first argument k
if arg = sy::F
then expr := subst(expr, [k], [(name op)::F])
else expr := subst(expr, [k], [opelt [(name op)::F,
replaceDiffs(arg, op,
sy)]])
-- => "iterate"
if is?(k, %diff) then
args := argument k
differentiand := replaceDiffs(subst(args.1, args.2 =
args.3), op, sy)
expr := subst(expr, [k], [opdiff differentiand])
-- => "iterate"
expr
seriesSolve(expr, op, sy, l) ==
ex := replaceDiffs(expr, op, sy)
f := compiledFunction(ex, name op, sy)$MKF
seriesSolve(f(#1, monomial(1,1)$UTSSUPF), l)$TaylorSolve(F, UTSF,
UTSSUPF)
@
%$
\section{Bugs}
<<inp: seriesSolve>>=
seriesSolve(sin f x / cos x, f, x, [1])$EXPRSOL(INT, EXPR INT, UFPS EXPR INT,
UFPS SUPEXPR EXPR INT)
@
returns
\begin{verbatim}
(((0 . 1) 0 . 1) NonNullStream #<compiled-function |STREAM;generate;M$;62!0|> .
UNPRINTABLE)
\end{verbatim}
but
<<inp: seriesSolve>>=
U ==> UFPS SUPEXPR EXPR INT
seriesSolve(s +-> sin s *((cos monomial(1,1)$U)**-1)$U, f, x, [0])$EXPRSOL(INT,
EXPR INT, UFPS EXPR INT, UFPS SUPEXPR EXPR INT)
@
works. This is probably due to missing [[/]] in [[UFPS]].
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
