Nice!
Thanks,
--
Raul
On Fri, May 6, 2022 at 10:51 PM Henry Rich <henryhr...@gmail.com> wrote:
>
> I have fixed this for next beta (but testing at the top, not in the loop).
>
> Henry Rich
>
> On 5/6/2022 9:25 PM, Raul Miller 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
>
>
> --
> 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
