Sure, but that's not prescriptive here. Here, we have a case where there is no result because _. (approximately speaking) gives an unhandled infinity as an unrecognized loop condition.
My gut feeling is that this means that we should treat this as an example of a case where the result would be _. if we could compute it (which means that we should throw a NaN error). Thanks, -- Raul On Fri, May 6, 2022 at 5:50 PM Ian Clark <earthspo...@gmail.com> wrote: > > Henry's right – though I doubt he can speak from experience. I can. > > I once thought I had a use for Indeterminate (_.) . I employed it > extensively in 'math/cal' to represent "unknown" (_.) and "invalid" (_.j_.) > values, after the manner of the old Mark IV data manipulation language, > where such pseudo-values really proved their worth. I was hoping to > systematically flag all values depending directly or indirectly on an > invalidated value. > > I soon found that the only "systematic" thing I had done was to import a > truckload of gremlins into my addon, and into anyone's code that was > misguided enough to load it. As in hindsight you'd expect with a "value" > that's not even equal to itself… > > z=: _.j_. > > z > > _.j_. > > z=z > > 0 > > > Then I read Roger Hui's essay: > https://code.jsoftware.com/wiki/Essays/Indeterminate -and heartily wished > that I'd read it sooner. > > > I fully endorse Roger's emphatically stated view that (_.) has no good use > inside operational code, and that all its occurrences should be eliminated > as soon as possible. I speak as one who has tried. If anyone out there > secretly imagines he could find a use in his code for (_.) I implore him to > read Roger's essay > > > Indeterminate (_.) is the J counterpart of radium patent medicine: > https://i.pinimg.com/736x/e0/85/fa/e085fa2a1d227031158fc7b158304e05.jpg > > > Ian Clark > > > > On Fri, 6 May 2022 at 20:53, Raul Miller <rauldmil...@gmail.com> wrote: > > > That's fine, but this example can occur unintentionally. > > > > For example, using gcd on a result from a dll call. > > > > -- > > Raul > > > > On Fri, May 6, 2022 at 3:48 PM Henry Rich <henryhr...@gmail.com> wrote: > > > > > > I think what happened was, Roger tried to figure out a way to make NaN > > > behave well but was unable to do so. In the end, he threw up his hands > > > and created NaN error for when we generate a NaN, and let the devil take > > > the hindmost if you use one intentionally. Where he put so much > > > thought, I don't expect to find a better solution. > > > > > > Henry Rich > > > > > > On 5/6/2022 3:44 PM, Raul Miller wrote: > > > > The distinction between "undefined" and "NaN" is a distinction of > > > > convenience, not a distinction of merit. > > > > > > > > > > > > > -- > > > 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 > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
