Which I now notice references this essay: https://code.jsoftware.com/wiki/Essays/Newton%27s_Method .
On Sat, Dec 25, 2021 at 3:59 PM Devon McCormick <[email protected]> wrote: > There is an example of Newton-Raphson here: > https://code.jsoftware.com/wiki/NYCJUG/2010-11-09#Newton.27s_method . > > On Sat, Dec 25, 2021 at 2:17 PM Henry Rich <[email protected]> wrote: > >> 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 >> > > > -- > > Devon McCormick, CFA > > Quantitative Consultant > > -- Devon McCormick, CFA Quantitative Consultant ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
