What I meant was, if you are tempted to add verbs for various domains, datatypes, definitions of integration, etc, you don't have a complete spec.  That's where I think we are with d./D. .  You will end up with two entry points defined as primitives, and who knows how many as named verbs.  The correct number of primitives for an application like that is 0.

Henry Rich

On 12/25/2021 2:08 PM, Raul Miller wrote:
On Sat, Dec 25, 2021 at 11:11 AM Henry Rich <[email protected]> wrote:
It is possible to have d. and D. call an addon, but I don't see that
that makes it much better.  And, primitives should only be functions
that have a cast-iron spec.
I believe that d. and D. do have a cast iron spec. The problem we face
with them is the implementation of that spec is daunting.

Past practice here has been to throw nonce errors for parts of the
infinite domain which are currently not treatable and to construct
verbs who return the primary value when that's an issue and a domain
error for values where the original function was known to be not
differentiable.

That said, J's documentation should document the limitations of
floating point numbers at least briefly, and should similarly document
the limitations of analytic mechanisms like d. and D. at least
briefly.

(And, in this context, it's worth noting that the "cast iron spec" for
floating point numbers has resulted in the industry supporting quite a
variety of floating point numbers -- J supports a subset of those
formats, with one which fits the host machine's architecture as the
primary format. This is relevant here because the limitations on
floating point numbers are intimately tied to limitations of
approaches for the d. family of operations.)

(Also, I think that the d. documentation should have an implementation
of the Newton Raphson algorithm as an example.)

Thanks,



--
This email has been checked for viruses by AVG.
https://www.avg.com

----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to