It's certainly better than before. Nevertheless, IMO there is still a mess
concerning the usage of "eval". In LISP eval/apply macro/function are
properly defined, but it seems to me that "eval" here is used more like
"subst" and moreover, "==" behaves like "==>" reagrding "D". I have a
conceptional problem in accepting the possibility g(x,x) <> eval(g(x,y),
y=x), when g is a function (else if g was defined as a macro). Am I barking
up the wrong tree?
Before
======
g(x,y) == D(f(x,y),x)
interpret(g(x,x)::INFORM)
(1) 2 f (x,x) + 2 f (x,x)
,2 ,1
Type:
Expression(Integer)
g(x,x)::INFORM
(2) (+ (D (f x x) (:: x Symbol)) (D (f x x) (:: x Symbol)))
Type:
InputForm
but
(3) -> g(x,x)
(3) f (x,x) + f (x,x)
,2 ,1
Type:
Expression(Integer)
After patch
========
(1) -> interpret(g(x,x)::INFORM)
(1) f (x,x) + f (x,x)
,2 ,1
Type:
Expression(Integer)
$ patch fspace.spad fspace.diff
; compiling file "C:/msys64/home/kfp/patches/FS2.NRLIB/FS2.lsp" (written 18
FEB 2019 10:26:58 PM):
; wrote C:/msys64/home/kfp/patches/FS2.NRLIB/FS2.fasl
; compilation finished in 0:00:00.018
------------------------------------------------------------------------
FunctionSpaceFunctions2 is now explicitly exposed in frame initial
FunctionSpaceFunctions2 will be automatically loaded when needed
from /msys64/home/kfp/patches/FS2.NRLIB/FS2
(1) -> f:=operator 'f
(1) f
Type:
BasicOperator
(2) -> g(x,y) == D(f(x,y),x)
Type:
Void
(3) -> g(x,y)
Compiling function g with type (Variable(x), Variable(y)) ->
Expression(Integer)
(3) f (x,y)
,1
Type:
Expression(Integer)
(4) -> g(x,x)
Compiling function g with type (Variable(x), Variable(x)) ->
Expression(Integer)
(4) f (x,x) + f (x,x)
,2 ,1
Type:
Expression(Integer)
(5) -> g(x,x)::INFORM
(5) (+ (eval (D (f x %C) %C) %C x) (eval (D (f %B x) %B) %B x))
Type:
InputForm
(6) -> eval(g(x,y),x=y)
(6) f (y,y)
,1
Type:
Expression(Integer)
(8) -> h(x,y) == x^2*sin(y)
Type:
Void
(9) -> h1(x,y) == D(h(x,y),x)
Type:
Void
(10) -> h1(x,y)
Compiling function h with type (Variable(x), Variable(y)) ->
Expression(Integer)
Compiling function h1 with type (Variable(x), Variable(y)) ->
Expression(Integer)
(10) 2 x sin(y)
Type:
Expression(Integer)
(11) -> h1(x,x)
Compiling function h with type (Variable(x), Variable(x)) ->
Expression(Integer)
Compiling function h1 with type (Variable(x), Variable(x)) ->
Expression(Integer)
2
(11) 2 x sin(x) + x cos(x)
Type:
Expression(Integer)
(12) -> eval(h1(x,y),x=y)
(12) 2 y sin(y)
Type:
Expression(Integer)
(13) -> eval(h1(x,y),y=x)
(13) 2 x sin(x)
Type:
Expression(Integer)
(14) -> h1(s,s)
Compiling function h with type (Variable(s), Variable(s)) ->
Expression(Integer)
Compiling function h1 with type (Variable(s), Variable(s)) ->
Expression(Integer)
2
(14) 2 s sin(s) + s cos(s)
Type:
Expression(Integer)
(15) -> h1(s,t)
Compiling function h with type (Variable(s), Variable(t)) ->
Expression(Integer)
Compiling function h1 with type (Variable(s), Variable(t)) ->
Expression(Integer)
(15) 2 s sin(t)
Type:
Expression(Integer)
On Monday, 18 February 2019 18:03:58 UTC+1, Waldek Hebisch wrote:
>
> Martin R wrote:
>
> > Here is a proposed fix:
>
> Could you say more how it is supposed to work? AFAICS
> obiously correct method would introduce new symbols and
> use eval. Other cases are optimizations to get simpler/
> nicer output. You change several things, most seem
> to be irrelevant, but curcialy I do not see creation
> of new symbols.
>
> --
> 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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/b1eaa21e-7104-45ca-b823-dce7e20c857a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
