Waldek Hebisch <[EMAIL PROTECTED]> writes:

> Try:
> 
> eval(deq, y, z+->exp(-z))
> 
> or
> 
> eval(deq, y, z+->eval(res, [x = z]))

Oh dear, yes, I was afraid that something like that would be the reason...

Actually, I do not really understand what smprep is supposed to do.  The doc
says:

 -- op(arg)**m ==> func(arg)**(m quo n) * op(arg)**(m rem n)

but that's a little cryptic.  I'd prefer:

-- within [EMAIL PROTECTED] replace 
-- op(arg)**m with func(arg)**(m quo n) * op(arg)**(m rem n)
-- where m = ... and n = ...
    smprep    : (List SY, List N, List(List % -> %), MP) -> %
    smprep(lop, lexp, lfunc, p) ==

but I still do not know what m and n are.  Unfortunately, it seems to be
impossible to output or PRINT$Lisp p and also the result of smprep, since the
result contains cycles.

> 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.

Hm, yes, but in this situation I think it should.  At least, it seems to me
that from a user's perspective

f: EXPR INT -> EXPR INT := x +-> res

and

f: EXPR INT -> EXPR INT := x +-> exp(-x)

are equal.  I'll look a little more into it.

(I thought that I understood dummies - at least in COMBF - but it seems I was
mistaken)

Martin


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to