Thanks for your interesting observations, Elijah. I replied in-line below.
Best regards,
Jan-Pieter
On Fri, 30 Sept 2022, 06:38 Elijah Stone, <elro...@elronnd.net> wrote:
> I have no control over the calculus addon, but I mark the equivalent
> treatment
> of &. and &.: and therefore would like to ask a clarifying question. Is
> it
> assumed that all verbs to be derived are applied monadically at rank 0? I
> can
> imagine an implementation of multivariate calculus would be interesting,
> but
> that may be out of scope. (But then, you mention neural networks, so
> maybe
> not? I am very ignorant about those, but I understand gradient descent is
> usually done in a high number of dimensions.)
>
This is indeed something I'd like to at least discuss about: if a user
passes in something with @: but is returned something using @ instead, I'd
say it is wrong. For now, it seems the addon assumes the result should only
work when applied at rank 0, but I think it would be more generally
correct, and still applicable as rank 0, if the result preserves the ":"
(lets call it rank-ignorance). I also coded the implementation of &. and
&.: as such; perhaps it can be a proof-of-concept for the other composition
conjunctions.
Multivariate differentiation (i.e. Jacobians) are also within scope, which
is what the pderiv conjunction provides.
The simplification pr is also interesting. It hints that what is actually
> wanted is a j computer algebra system: the deriver and integrator should
> generate expressions that are as messy as they would like to be, and then
> a
> simplifier should make the results look nice. And all three of those
> should
> just be components of a larger system.
>
Generally speaking, more or less. Ideally the simplifier should be called
en-route, because the derivstg and family (doing differentiation on string
representations) call themselves all the time, which is why in the current
version, things like 1&o. deriv 100 blow up.
>
> I do not think there are resources to build anything approaching the level
> of
> mathematica, but it is something to think about. A good start would be to
> change the representation used to something more amenable to machine
> computation than j gerunds, generating j verbs only for final display to
> the
> user.
This is, partly, what the calculus addon does. It works with atomic
representations, which appears to be (I've nearly no CS background) a
parsed tree structure of any J entity.
I suggest the following representation, which I have had great success
> with thus far in my j compiler: represent an expression with a dataflow
> graph,
> in two parts: the first, a pair of integer vectors 'from' and 'to'
> indicating
> the graph structure, such that, for any i, there is an edge going from
> node
> i{from to node i{to; the second, a collection of lists of node attributes.
> Ordering is expressed implicitly in the order of the edges; for instance,
> in
> x+y, the edge going from + to x must appear earlier than the edge going
> from +
> to y in from and to. To begin with, a node can have only a name as an
> attribute (or a noun-value, if it is known to be constant).
>
Certainly worth looking into. I'd do the edge to y first, to stick with J's
right to left evaluation. Even if we should not really care because it's a
non-standardised implementation detail, this is the behaviour of forks at
the moment. It makes a difference when y or x have side effects.
>
> This representation is well-suited to concise, efficient, and parallel
> traversal using /. . Transformations on the graph can be represented as
> deltas returned by the key function. I may write more on this in the
> future.
>
> Bringing the system to the point where people can write patterns (such as
> xāā0+x, or (f+g)deriv nāāf deriv n+g deriv n) would make a huge
> difference, as it would open up the floor for contributions from anybody.
>
I don't know whether this is possible, at least not with the current setup:
deriv executes, and thus disapears, the moment it is applied to its
arguments... Internally, the addon already uses this identity, see e.g.
here
https://github.com/jpjacobs/math_calculus/blob/9bd4db576956382a8cd09e8fa6b1564317f58eed/calculus.ijs#L172
>
> I would also suggest the use of e-graphs (https://egraphs-good.github.io/),
> as
> it seems to me that they are uniquely suited to computer algebra systems,
> and
> in particular that they reduce the work required to build a decent one.
> But I
> have not as yet given any thought to what a good representation of
> e-graphs
> would look like in j.
>
I'll take a look :). Thanks for the pointer.
>
> I don't mean to impose any work on anybody. These are just my thoughts on
> what it would take to make the calculus addon really amazing, which I do
> not
> have the time or energy to execute on myself right now; but if you (or
> anybody
> else) are interested in taking it over and exploring further, I am happy
> to
> discuss more.
>
> -E
>
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
