"Raul Miller" <[EMAIL PROTECTED]> wrote: > On 4/16/08, Mark D. Niemiec <[EMAIL PROTECTED]> wrote: > > However, the point I was trying to make is that 0+._ should > > be _, just like 0*_ and 0%0 are. These all have consistent > > arguments, > > 0+._. has an inconsistent argument.
Yes, but I was talking about 0+._ and not 0+._. (what a difference a dot makes!) > I agree that J should not crash, but other than that, making > the code complicated or slower to deal with an inconsistent > case seems like a trivial benefit for a non-zero cost. Verbs such as +. (and = ~: < <: > >: and monads * <. >. that involve comparison tolerances) already involve non-trivial algorithms that are better encoded in software functions rather than hardware primitives, so in such cases, checking for specific values (such as 0 or _) is not nearly as burdensome as doing so for hardware-defined functions such as + - * and % . In fact, tolerant comparisons MUST already perform such a check for _, since the tolerant equality algorithm fails if one of the parameters is infinite. t =: 2^_44 teq =: |@- <:!.0 t * >.&| 3 teq 4 0 3 teq _ 1 Also, in order to implement more elegant product semantics, J already performs checks for zero in * and %, even though those are implemented in hardware (so such checks would have a more severe penalty than doing so for software algorithms, as above). > Anyways, perhaps a better approach would be to define an > adverb _.: which produces a verb with the same ranks as > its argument and which produces a domain error if any > argument to that derived verb contains _. You can do that now: N =: 1 : 'u`[: @. (>.&(128!:5)) " u' 3 =N 4 0 3 = _. 0 3 =N _. |domain error | 3 =N _. -- Mark D. Niemiec <[EMAIL PROTECTED]> ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
