On 17 November 2016 at 07:41, Bill Page <[email protected]> wrote:
>
> Again, here is another draft. The latest version of the code is here:
>
>
https://github.com/billpage/fricas/commit/c22aa634311e19153681b02ff02f3a6a02033d64
>
I got it, thank you.
(2) -> x:SEXPR(INT)
Type:
Void
(3) -> x
(3) x
Type:
SymbolicExpression(Integer)
(4) -> y:SEXPR(INT)
Type:
Void
(5) -> x-x
(5) x - x
Type:
SymbolicExpression(Integer)
(6) -> x^n
n
(6) x
Type:
SymbolicExpression(Integer)
(7) -> n
(7) n
Type:
Variable(n)
(8) -> D(x^n,x)
There are 5 exposed and 2 unexposed library operations named D
having 2 argument(s) but none was determined to be applicable.
Use HyperDoc Browse, or issue
)display op D
to learn more about the available operations. Perhaps
package-calling the operation or using coercions on the arguments
will allow you to apply the operation.
Cannot find a definition or applicable library operation named D
with argument type(s)
SymbolicExpression(Integer)
SymbolicExpression(Integer)
Perhaps you should use "@" to indicate the required return type,
or "$" to specify which version of the function you need.
(8) -> (x+y)^x
x
(8) (x + y)
Type:
SymbolicExpression(Integer)
(9) -> exp(-x)
(9) exp(x)
Type:
SymbolicExpression(Integer)
(10) -> -x
(10) x
Type:
SymbolicExpression(Integer)
(11) -> exp(-x)::InputForm
(11) (exp (- x))
Type:
InputForm
Apparently "-" is consumed by OutputForm ?
> I am not really sure if what I started with makes sense. In contrast
> to my original Symbolic constructor, in this new version
> SymbolicExpression does not try to make everything "symbolic" but
> rather only those domains which can also be Expression. The
> difference between Expression and SymbolicExpression is intended to be
> only that the expression remains unevaluated but otherwise it is
> treated exactly like Expression.
Makes sense to me as well. Expressions are the quintessence and it's of
vital importance that they can be (re-)used as such, otherwise we could
just use rewriting rules on a purely symbolic type.
Nevertheless I'm still confused. If you look at the following example (code
at the end) you'll see that there already are certain possibilities to use*
symbols* in *Expression*. What is N? Mathematically we certainly agree that
N=0,1,2,... was meant, on the other hand N has type Symbol, i.e. could be
almost anything (e.g. _+, actually it is so when 'N <--> '+).
The advantage is, however, we can evaluate the sum, thus removing any
"symbolic" ambiguity. The disadvantage (as I rate it) is that it's a
tiresome thing to perform any symbolic manipulations on the 'formal' sum
below (though feasible).
(2) -> fourierSum('N,z*sin(z),z=0..%pi)
N 2 - 2%i n %pi 2%i n z
--+ (((- 4n + 1)%pi + 4%i n)%e + 4%i n)%e
(2) > --------------------------------------------------------
--+ 4 2
n = - N (16n - 8n + 1)%pi
Type:
Expression(Complex(Integer))
(3) -> eval(%,N=2)
(3)
4%i z 2%i z
(- 15%pi + 16%i)%e + (- 75%pi + 200%i)%e
+
- 2%i z - 4%i z
(- 75%pi - 200%i)%e + (- 15%pi - 16%i)%e + 225%pi
/
225%pi
Type:
Expression(Complex(Integer))
>The thing that I began to worry about
> was what exactly should
>
> x:Symbolic(Integer)
>
> mean.
I've mediated for a long time over such questions - with little tangible
results. With respect to the example above I would say that
N:Symbolic(Integer) is the same as when saying $N \in \mathbb{Z}$. It would
certainly forbid accepting nonsense like '+. Moreover, it might ensure that
N could be evaluated to an Integer only, nothing else.
Now you have renamed Symbolic to SymbolicExpression, so the above remarks
are not valid any more, however, it might even be beneficial if we want set
N=2*M for example.
> For example does the Symbolic(Integer) domain contain
> expressions like 'sin(x)' and 'sqrt(x)' ? If we answer "no" then it
> seems to me that the usefulness of such a domain is extremely limited.
No question, the domain should contain all these expression.
For example (f:=operator 'f)
(8) -> integral(D(f(x),x)*g(x),x=a..b)
b
++ ,
(8) | g(x)f (x)dx
++
a
Type:
Expression(Integer)
is a typical candidate for what I have in mind. As soon as f is "sin" for
example, the derivative will be performed (-> cos). With Expression one
must be very careful which terms are going to be used to keep it formal.
With SymbolicExpression this ought to be much more convenient. For
instance, if I want to perform a partial integration of (8) then I'll write
a function returning the well known result as a SymbolicExpression.
Eventually I can coerce it to Expression(Integer), if I like to ;)
>
> What do you think?
>
> --
Some years ago we've embedded REDUCE into the Pure language
http://puredocs.bitbucket.org/pure-reduce.html - which is a functional
programming language based on term rewriting. The reason was because even
writing a simplifier from scratch is a formidable task using but a
rewriting system. If you look into to the quickref
http://purelang.bitbucket.org/quickref/pure-quickref.pdf you'll see that
it's perfect to perform any symbolic transformations you can imagine but
it's hard (if not impossible) to do reliable computations as in Fricas -
unless you port the "algebra" to Pure (the Pure interpreter is even more
Spartan than fricas').
I think we need a compromise and you're on the right track. Let me know if
I can be of any help.
Little strokes fell big oaks.
-----------
)abbrev package FOURIER Fourier
Fourier() : Exports == Implementation where
INT ==> Integer
SYM ==> Symbol
CI ==> Complex INT
XCI ==> Expression CI
XI ==> Expression INT
SBX ==> SegmentBinding XCI
LAP ==> LaplaceTransform(CI,XCI)
Exports == with
coeff : (SYM,XCI,SBX) -> XCI
fourierSum : (SYM,XCI,SBX) -> XCI
fourierTransform : (XCI,SYM,SYM) -> XCI
Implementation == add
coeff(n,f,sb) ==
n:XCI:=coerce(n)$XCI
xs:SYM:=variable(sb)
x:XCI:=coerce(xs)$XCI
c:XCI:=c:XCI:=coerce(2)$XCI*coerce(complex(0,1))$XCI*pi()$XCI
s:Segment(XCI):=segment(sb)
a:XCI:=lo s
b:XCI:=hi s
r:XCI:=f*exp(-c*x*n/(b-a))
I1:XCI:=complexIntegrate(r,xs)$FunctionSpaceComplexIntegration(CI,XCI)
(eval(I1,x=b)-eval(I1,x=a))/(b-a)
-- eval(coeff('n,sin(x),x=0..%pi),n=0)
fourierSum(N,f,sb) ==
N:XCI:=coerce(N)$XCI
n:XCI:=coerce('n)$XCI
xs:SYM:=variable(sb)
x:XCI:=coerce(xs)$XCI
c:XCI:=c:XCI:=coerce(2)$XCI*coerce(complex(0,1))$XCI*pi()$XCI
s:Segment(XCI):=segment(sb)
a:XCI:=lo s
b:XCI:=hi s
r:XCI:=exp(c*x*n/(b-a))
cr:XCI:=coeff('n,f,sb)
sbr:SBX:=equation('n,segment(-N,N))
sum(cr*r,sbr)$FunctionSpaceSum(CI,XCI)
--
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.
