Roger Hui wrote:
> Actually, symbolic computations can be done as
> yet another datatype and the only cost ("sacrifice")
> would be implementation effort that could be
> expended in other areas. You can look at f&.g and
> f b. _1 for indications of what can be done with
> symbolics in J.
I understand and appreciate what can be done symbolically in J (and I
am constantly amazed at the scope of b._1). The type of issue I am
talking about involves the way in which symbolic languages are
normally implemented:
(a) Having a large number of data types to represent expressions, and
being able to convert between them. For example, rational function
may be represented most appropriately as a quotient of fully factored
polynomials or in partial fractions, depending on context.
(b) Maintaining a unique instance of the simplification of every
expression. This is necessary to cope with the intermediate
expression swell that otherwise dogs symbolic computation.
(c) Using a large collection of simplification rules. This is needed
if you want to get textbook solutions to college-level math problems.
For example, Maple will give the exact solution to the initial value
problem y''-2y=x exp(x), y(0)=1, y'(0)=2 by entering it in essentially
this form.
> dsolve({diff(y(x),x,x)-2*y(x)=x*exp(x),y(0)=1,D(y)(0)=2});
y(x) =
/ 1/2 \ / 1/2\
1/2 |5 2 | 1/2 | 5 2 |
exp(2 x) |------ + 3/2| + exp(-2 x) |3/2 - ------| - (2 + x) exp(x)
\ 4 / \ 4 /
However, this capability has a huge price: the infrastructure
described above, which is applied to every expression. Symbolic
calculation at this level of generality is very useful, but in quite
limited contexts. If it can be parcelled off so that it does not
affect non-symbolic computation, that would be great. I think it is a
lot of work, though.
Best wishes,
John
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
