This is mostly a note to myself:
_.~:_.
1
So, either _. needs to be tested for explicitly, or an equality test
along the lines of -.@(<+.>) needs to be used. (And, with !.0 on the
inside, if comparison tolerance needs to be ignored...).
And that's assuming someone hasn't gotten cute with the underlying
implementation...
--
Raul
On Fri, May 6, 2022 at 9:25 PM Raul Miller <rauldmil...@gmail.com> wrote:
>
> Hmm...
>
> Ok, so what I think this means is that if we do not want gcd to hang
> forever on some arguments we would in effect need to use -.@= in
> euclid's algorithm instead of ~:
>
> Or, more specifically, in ve.c
>
> D jtdgcd(J jt,D a,D b){D a1,b1,t;B stop = 0;
> a=ABS(a); b=ABS(b); if(a>b){t=a; a=b; b=t;}
> ASSERT(inf!=b,EVNAN);
> if(!a)R b;
> a1=a; b1=b;
> while(remdd(a1/jround(a1/a),b1)){t=a; if((a=remdd(a,b))==0)break;
> b=t;} // avoid infinite loop if a goes to 0
> R a;
> } /* D.L. Forkes 1984; E.E. McDonnell 1992 */
>
> we should be testing for _. to avoid an infinite loop.
>
> It might be sufficient to replace if((a=remdd(a,b))==0)break; with
> if(!(a=remdd(a,b))!=0)break; (though it's possible that a compiler
> might "optimize" that expression and break it).
>
> But, this routine should either return a result or it should throw an error.
>
>
> --
> Raul
>
> On Fri, May 6, 2022 at 7:26 PM Henry Rich <henryhr...@gmail.com> wrote:
> >
> > Just try adding _. + 4 .
> >
> > Henry Rich
> >
> > On 5/6/2022 6:47 PM, Raul Miller wrote:
> > > Huh?
> > >
> > > My understanding was that the only acceptable sources of _. were:
> > > direct entry, evaluation, 3!:n and DLL calls.
> > >
> > > And, that the only primitives which were allowed to produce results
> > > containing _. were structural primitives which move data without
> > > interpreting it.
> > >
> > > --
> > > Raul
> > >
> > >
> > >
> > > On Fri, May 6, 2022 at 5:58 PM Henry Rich <henryhr...@gmail.com> wrote:
> > >> No. _. + 4 is not a NaN error. _ - _ is NsN error.
> > >>
> > >> This result should be _. with no error.
> > >>
> > >> Henry Rich
> > >>
> > >> On 5/6/2022 5:55 PM, Raul Miller wrote:
> > >>> 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,
> > >>>
> > >>
> > >> --
> > >> 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
> >
> >
> > --
> > 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
