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, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
