Re: [Jprogramming] bug: _. and logical operations

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

Re: [Jprogramming] bug: _. and logical operations

Nice! Thanks, -- Raul On Fri, May 6, 2022 at 10:51 PM Henry Rich 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 h

Re: [Jprogramming] bug: _. and logical operations

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

Re: [Jprogramming] bug: _. and logical operations

You are right. 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

Re: [Jprogramming] bug: _. and logical operations

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;}

Re: [Jprogramming] bug: _. and logical operations

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 p

Re: [Jprogramming] bug: _. and logical operations

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, 202

Re: [Jprogramming] bug: _. and logical operations

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

Re: [Jprogramming] bug: _. and logical operations

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 _.

Re: [Jprogramming] bug: _. and logical operations

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 pseud

Re: [Jprogramming] bug: _. and logical operations

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 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

Re: [Jprogramming] bug: _. and logical operations

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'

Re: [Jprogramming] bug: _. and logical operations

The distinction between "undefined" and "NaN" is a distinction of convenience, not a distinction of merit. -- Raul On Fri, May 6, 2022 at 3:27 PM Elijah Stone wrote: > It is undefined. Operations on nan are not guaranteed to produce anything > sensible (except structural operations and 128!:5)

Re: [Jprogramming] bug: _. and logical operations

It is undefined. Operations on nan are not guaranteed to produce anything sensible (except structural operations and 128!:5). On Fri, 6 May 2022, Raul Miller wrote: But what should the result of _. +. 1 be, if not NaN? Thanks, -- Raul On Fri, May 6, 2022 at 2:46 PM Henry Rich wrote: US

Re: [Jprogramming] bug: _. and logical operations

But what should the result of _. +. 1 be, if not NaN? Thanks, -- Raul On Fri, May 6, 2022 at 2:46 PM Henry Rich wrote: > > USING a NaN is not an error. The result is undefined (sc whatever the > hardware produces). CREATING a NaN is an error. > > _. = 4 > 0 > _. + 4 > _. > _ % _

Re: [Jprogramming] bug: _. and logical operations

USING a NaN is not an error.  The result is undefined (sc whatever the hardware produces).  CREATING a NaN is an error.    _. = 4 0    _. + 4 _.    _ % _ |NaN error |   _    %_ 1 +. _. is not a Boolean operation.  It's calculating the LCM. NANTEST calls the OS to see if any NaN-creating operat

Re: [Jprogramming] bug: _. and logical operations

Hmm... actually, there's a bunch of tests like this already there, with comments that NaN errors are treated as zeros in this context. Which suggests that I was wrong about what the fix should be. I'll shut up now... -- Raul On Fri, May 6, 2022 at 2:32 PM Raul Miller wrote: > > Looking at the

Re: [Jprogramming] bug: _. and logical operations

Looking at the J implementation, it's pretty clear that jsignal(EVNAN); R 0; would signal the NaN error. But J has a macro -- NANTEST -- which I don't adequately understand, and a variation of this logic is used in the NAN1 macro. (I was looking at the implementation to try and figure out what ki

Re: [Jprogramming] bug: _. and logical operations

Yes: _. in an argument here should signal a NaN error. Thanks, -- Raul On Fri, May 6, 2022 at 7:15 AM Elijah Stone wrote: > > _. may give garbage results. It shouldn't hang. > > On Fri, 6 May 2022, Razetime wrote: > > > Although this does not seem like intended behaviour, it is worth mention

Re: [Jprogramming] bug: _. and logical operations

strings. I prefer to use _. as the default value because I could vaguely consider using _ and __ as authorized values some day. But I will stick with __ this time round.) De : Elijah Stone À : programm...@jsoftware.com Sujet : Re: [Jprogramming] bug: _. and logical operations Date : 06/0

Re: [Jprogramming] bug: _. and logical operations

_. may give garbage results. It shouldn't hang. On Fri, 6 May 2022, Razetime wrote: Although this does not seem like intended behaviour, it is worth mentioning that NuVoc explicitly states that _. is not recommended for use in J computation

Re: [Jprogramming] bug: _. and logical operations

Although this does not seem like intended behaviour, it is worth mentioning that NuVoc explicitly states that _. is not recommended for use in J computations. On Fri, May 6, 2022 at 4:30 PM wrote: > Hello, > > > > _. does not mix well with lo

[Jprogramming] bug: _. and logical operations

Hello, _. does not mix well with logical operators. The following hang and use a lot of CPU on J 9.03 (Windows and Linux): 1 +.  _. 1 *. _. +. / 8 0 _. Note, that I have no particular use for these sentences, I just stumbled across them due to a bug in my program. Philip ---