Martin Rubey
>
>
> If somebody could help debugging this, it would be great...
>
> (it would already be very helpful to know exactly which implementation of eval
> is called in the end...)
>
AFAICS eval(%, SY, (EXPR INT -> EXPR INT)) in ExpressionSpace calls
eval(%, List SY, List(List EXPR INT -> EXPR INT)) in FunctionSpace
which calls eval(%, List SY, List INT, List(List EXPR INT -> EXPR INT))
in FunctionSpace:
eval(x:%, s:List SY, n:List N, f:List(List % -> %)) ==
smprep(s, n, f, numer x) / smprep(s, n, f, denom x)
> Martin
>
> (1) -> y := operator 'y
>
> (1) y
> Type: BasicOperator
> (2) -> deq := differentiate(y x, x) + y x
>
> ,
> (2) y (x) + y(x)
>
> Type: Expression(Integer)
> (3) -> res := first(solve(deq, y, x).basis)
>
> - x
> (3) %e
> Type: Expression(Integer)
> (4) -> eval(deq, y, x+->res)
>
> - x
> (4) %e
> Type: Expression(Integer)
>
Try:
eval(deq, y, z+->exp(-z))
or
eval(deq, y, z+->eval(res, [x = z]))
It seems that you want "variable capture", but code for evaluating
derivative is very careful to distinguish x contained in res from
x in deq. Look at begining of smprep:
smprep(lop, lexp, lfunc, p) ==
(v := mainVariable p) case "failed" => p::%
-- symbolIfCan(k := v::K) case SY => p::%
k := v::K
g := (op := operator k)
(arg := [eval(a,lop,lexp,lfunc) for a in argument k]$List(%))
q := map(eval(#1::%, lop, lexp, lfunc),
now:
(10) -> mainVariable numer deq
,
(10) y (x)
Type: Union(Kernel Expression Integer,...)
(11) -> operator mainVariable numer deq
(11) %diff
Type: BasicOperator
(12) -> argument mainVariable numer deq
(12) [y(%%01),%%01,x]
Type: List Expression Integer
You see that derivative is usig special dummy variable, so I would
guess that the intent it _not_ to capture any other x that just
happens to be in the expression. Apparently this dummy is
passed to substitution function, so it can insert the dummy inside
replacement expression.
Now, without deeper analysis I can not say if substitution works
as intended, but clearly original authors wanted to avoid
accidental variable capture. It is not clear if the above
bahaviour should be considerd a feature, a bug. Possibly it is
just a tradeoff requireing more complicated use but allowing
simple prevention of unwanted variable capture. Currently
variable capture is avoided using dummies, but to allow
intentional capture one would have to analyze at each point
when derivative (or sum or product, etc.) is computed which
variables are free and which are bound inside.
--
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
-~----------~----~----~----~------~----~------~--~---
