13 : in J would be a great idea (assuming you use the NB. primitive
liberally). The C code is hard to follow.
Henry Rich
On 10/5/2022 2:56 AM, Elijah Stone wrote:
I do not think there is any reason to use rust or ffi.
I think the concerns of a cas are different from those of a compiler,
and
I do not think there is any reason to use rust or ffi.
I think the concerns of a cas are different from those of a compiler, and no
attempt should be made to join the two. To give one pertinent example: the
type language used in a compiler should be total, whereas users should be able
to use
I don't think we need to model all of J here. The derivative of ": is
not going to be a thing, for example.
Building up from a useful core is probably the way to go. And that
starts with rank 0 numeric functions (followed by their higher ranked
analogs). Having enough documentation to keep core co
I took a quick glance at egraphs-good (egg) and I can see the
advantage. I just wonder whether a setup like this could manage with
the complexity required for fully modelling J.
For now the calculus addon pretty much manually codes every possible
combination, each with its own, adhoc structure. I
On Fri, 30 Sep 2022, Jan-Pieter Jacobs wrote:
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.
Ha, yes, I
Thanks for your interesting observations, Elijah. I replied in-line below.
Best regards,
Jan-Pieter
On Fri, 30 Sept 2022, 06:38 Elijah Stone, 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 qu
On Fri, Sep 30, 2022 at 12:52 AM Henry Rich wrote:
> I thought there was a rudimantary D.-replacement in the addon
> but my memory may be faulty.
Your memory is fine, mine... not so much.
Thanks,
--
Raul
--
For information abo
J already shares some of mathematica's strengths (interactivity, integrated
visualisation, data analysis). And I think a high quality symbolic
manipulator is well within reach. But
https://reference.wolfram.com/language/tutorial/SomeNotesOnInternalImplementation.html
gives some idea of its sh
I see, thanks. Comments indicate deriv is d. and pderiv is D.; I haven't
looked too closely yet.
Early macsyma would be great; like I said, I don't think mathematica is
remotely viable. I tried to provide a roadmap to get there because, from what
I can tell, the calculus addon is not even cl
The implementation of D. was buggy. I hope we can do better with the
addon. I thought there was a rudimantary D.-replacement in the addon
but my memory may be faulty.
With enough Jers contributing maybe this could be a competitor to
Mathematica. Time will tell.
Henry Rich
On 9/30/2022
Yes, rank 0 a valid assumption. Sort of:
J used to have two derivative words, d. (rank 0) and D. (jacobian).
As near as I can tell, the library only replaces d. and does not yet
provide a D. implementation.
That said... I would not think of this as a mathematica competitor --
more like an early
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 in
Hi folks,
Mostly as a heads-up: I just submitted a pull-request for the
math/calculus addon which adds hooks, under, NVV forks and fixes some
bugs.
You can find it here: https://github.com/jsoftware/math_calculus/pull/9 .
Any comments are highly appreciated!
My main motivation for messing around
13 matches
Mail list logo
