Roger Hui <[EMAIL PROTECTED]> wrote: > It is an anomaly only if you can produce _. on arguments > not containing _. . >
> > 0 +. _ NB. Should probably be _ ((0 +. > > y) = (|y) for all real y) > > |NaN error > > | 0 +._ True. However, I think that in this case, _. shouldn't be produced at all (for much the same reason that J treats 0 = 0*_ and 0 = 0%0, even though the hardware produces NaN in both cases.) Mathematically, since 0 divides everything, 0+.y should be y for all y (or, in J's definition, |y for real y, or y*0j1^n for complex y, n e. 0 1 2 3, depending on *+.y). >From an inplementation perspective, checking for x=0 or y=0 should probably have minimum performance impact, since +. has to be done by an algorithm rather than by hardware anyway. And such testing already has to be done for * and % (which ARE done by hardware). > In short, when an argument contains _. , all bets are off. > > 1 +. _. NB. Oops! > > <infinite loop> Well, it's reasonable for J to produce anomalous or inconsistant results with _. or even to throw exceptions. However, crashes or infinite loops should be avoided by the interpreter whenever possible, regardless of data input. (sentences like >:^:_ can often loop, but primitives should never do so). -- Mark D. Niemiec <[EMAIL PROTECTED]> ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
