/\   Requests: Interpreter · Library · Jwdw · Jwdp   Bugs: Interpreter · Library · Jwdw · Jwdp

  • Please restrict the headings to just two levels, with the actual bug reports placed at the top level; sign your submission using @SIG@; register the entry in the comment field below.

J interpreter and Dictionary bug reports listed in the order when they were submitted.

Interpreter bug reports in 2005, 2006, 2007; library and frontend bug reports.

Contents

  1. evoke local names
  2. crash on infinite recursion
  3. value errors with special names
  4. linux 1!:0 access time used
  5. unspecified and inconsistent LHAs to zero-cut
  6. display of bonded conjunctions buggy
  7. spurious "non unique" error with dyad / and sparse arrays
  8. spurious errors from infinite infixes
  9. zero-length infix discrepancy
  10. crash on linear display of reassigment
  11. crash on f. while suspended
  12. 13&:'s result different from 4&:
  13. bugs in fixing hybrid tacit/explicit self-referential verbs (in anonymous definitions)
  14. final sentence of f. specification incorrect
  15. dyads #. and #: sensitive to type of empty RHA
  16. incorrect and inconsistent constant notation
  17. explicit operators don't recognize derived verb arguments in locatives
  18. security level out of date
  19. fixed verbs broken
  20. crash on take with rational args
  21. Rank Basic Wrong
  22. sparse of empty prefix crashes
  23. definition of monad ". unclear
  24. cannot exclude index from scalar
  25. crash on monadic amend of boxed jmf
  26. fsm corrupts memory
  27. rank with more than three numbers
  28. long train crash
  29. deep conversion crash
  30. define is permissive
  31. gerund referent not evoked
  32. dictionary defn for floor does not handle tolerance
  33. tall stack crash
  34. local/global nameclass confusion
  35. equalty too tolerant for complex numbers
  36. inverting hook recursion
  37. too many digits from base representation
  38. identity improperly optimized
  39. specification of verbal amend incomplete
  40. first use of adverb fails
  41. uninvestigated display crash
  42. ambivalent verbs improperly fixed
  43. Secondary problem
  44. Explicit to tacit conversion problem
  45. sparse polynomial crash
  46. extended root error
  47. nan won't do
  48. stacking the proverbial deck
  49. 128!:5] 0j_.
  50. Dictionary 6!:8 (Query Clock Frequency)
  51. Strange evoke of invalid gerund with fit

evoke local names

Evoke on verb arguments to explicit conjunctions and adverbs don't refer to local names; refer to global names. 

   useU    =.  2 : ' ''u.''~ ''n.''~'
   evokeU  =.  1 : ' ''u.''~ '

   +: useU 12    NB.  Correct
24
   +: evokeU     NB.  Bug
|value error: u.

   u. =. -:
   +: useU 12    NB.  Correct
24
   +: evokeU     NB.  Bug
-:

-- DanBron 2005-11-09 21:14:49


crash on infinite recursion

The second crash reported in the '06 crash on infinite recursion report is still outstanding. That is, f^:] 0&]`] crashes J.

-- DanBron 2006-09-14 14:53:07

This related crash occurs in the same environment as reported above

-- DanBron 2006-09-18 18:29:58


value errors with special names

The special names, which denote arguments to explicit definitions, are still treated differently from other names. 

   3 : '  ".  ''q'' ' 0  NB.  Fine

   3 : '  ".  ''n'' ' 0  NB.  Bug
|value error: n
|       n

   3 : ' q"_ :: 0: y' 0   NB.  Fine
0

   3 : ' u"_ :: 0: y' 0   NB.  Bug
|value error: u
|       u"_ ::0:y
   

   foo =: 3 : 0
        4!:55 {. ;: 'z'
        name_z =. + z     NB.  Fine (when verb executed)

        4!:55 {. ;: 'y'
        name_y =. + y     NB.  Bug  (when verb executed)
        ''
)
   
   foo ''
|value error: y
|   name_y=.+    y

A similar error occurs for the analogous cases of x m n u v where no such exception would be expected.

Note that this can cause unexpected problems when loading (or loadding or requireing) files which expect y to be a normal undefined name. Vide: 

   'foo =: + y' fwrite jpath '~temp\y.ijs'
10
   load '~temp\y.ijs'
|value error: y
|   foo=:+    y
|[-0] c:\app\j\current\temp\y.ijs

I thought this particular (loading) problem might be restricted to the name y, due to the phrase 4!:55<''y'' in the library definitions script and scriptd, but all the special names are so effected.

-- DanBron 2006-09-21 19:07:34


linux 1!:0 access time used

The documenation says that 1!:0 will return the file modification time. On Windows XP, this is correct. On Linux, 1!:0 shows the access timestamp. Example: 

   1!:0 'j*'
+----+-----------------+---+---+------+----------+
|j601|2006 9 30 7 37 35|512|rwx|----d-|drwxr-xr-x|
+----+-----------------+---+---+------+----------+

linux:~ # ls -ldu j601
drwxr-xr-x  6 root root 512 Sep 30 07:37 j601
linux:~ # ls -ld j601
drwxr-xr-x  6 root root 512 Sep 30 07:15 j601

-- DavidMitchell 2006-09-30 11:58:34


unspecified and inconsistent LHAs to zero-cut

The vocabulary entry for cut says (2271 582 qdoj ';.'):

However:

PS: There is a serious crashing bug related to infinites and zero-cut (at least when 2=#$y). But I'm weary of tracking these down. It would really help me if the JFE flushed all IJX input lines to disk (somewhere) before executing them. I've had to let 3 or 4 distinct types of crashes go unreported in the last month.

-- DanBron 2006-12-21 21:09:26


display of bonded conjunctions buggy

Similar to the sequence adverbs bug, certain typing adverbs raise errors when displayed:

   `(<'5')
|domain error
   (<'...')`: 
|spelling error

while the diplay of others is incorrect (misleading, ambiguous):

   `(<'`')
``
   (<'.')`:
 .`:

and others have no display at all: 

   a=.<3
   (((a=.<3)++)`)  ("_) (`a)
   NB.  No display

   e=. (((a=.<3)++)`)  ("_) (`a) 
   5!:5{.;:'e' 
|domain error
|       5!:5{.;:'e'
    NB.  Explicit request for display results in error
    NB.  (like earlier examples).

I suggest that the display of the form `(abn=.arbitrary boxed noun) should be '`(',')',~5!:5<'abn' except when abn happens to be the same as an atomic rep of a verb, in which case the display should be '`(',')',~]2 :'5!:5{.;:''v''' abn 5!:0, as now. If abn is the atomic rep of a primitive or named verb, the parentheses may be elided. Similar strategies apply to abn` and other conjunctions in place of ` .

In re: the <'hello'& example -- this turns out to be correct, but I still suggest

-- DanBron 2006-12-30 18:22:14


spurious "non unique" error with dyad / and sparse arrays

As reported in the Forums, phrases of the form sparseA f/ sparseB cause spurious (?) non-unique sparse elements errors:

   =/~ $. , 1
|non-unique sparse elements
|       =/~$.,1

I'm not positive this is a bug, because I'm not clear on when such errors are raised, but the documentation says ~-(3940 178 qdoj 'errors'):

and since the arguments to f/ are properly-formed sparse arrays, and the user has no further control of the sparse element specified within the logic of f/, the error is not his fault, and he cannot avoid it.

-- DanBron 2006-12-30 18:53:50


spurious errors from infinite infixes

Infix, dyadic (verb derived from) \, raises spurious errors when given an infinite LHA: 

        _  <\ i. 4        NB.  Fine

        _ 0:\ i. 4        NB.  Fine

        _  ]\ i. 4        NB.  Bug
|domain error
|   _    ]\i.4


        _  <\ i. 4        NB.  Fine

   ({., _) <\ i. 4        NB.  Weird!
|limit error
|   ({.,_)    <\i.4
        
   infinity0 =:      _  
   infinity1 =: {. , _    NB.  Identical to  _

   infinity0 -: infinity1 NB.  Matches
1
   
   infinity0 <\ i. 4      NB.  Fine

   infinity1 <\ i. 4      NB.  Bug
|limit error
|   infinity1    <\i.4
   
   infinity2 =: 3!:2 (3!:1) infinity0  NB.  Byte-identical to  _

   infinity2 <\ i. 4      NB.  Bug
|limit error
|   infinity2    <\i.4

   infinity2 <\ 0         NB.  Fine -- scalar RHA

   infinity2 0:\ 0        NB.  Fine

   infinity2 ]\ 0         NB.  Bug (still)
|domain error
|   infinity2    ]\0

       __ ]\ i. 4         NB.  Bug (still)
|domain error
|   __    ]\i.4

Oh yeah, and trateotu=:15!:7(15!:6)<'infinity'[infinity=:_ will crash J. What, I can't have a pointer to infinity? ;)

-- DanBron 2007-01-06 03:58:57


zero-length infix discrepancy

As asked in the Infix thread in the Forums: Is this right? 

   0 (<\ ,&# <;._3) i. 5
6 5

Look at the pattern: 

   inf   =:  2 : '(i. ->: n) #@u"0 _ i. <:n'
   inf5  =:  inf 5
        
   <\ inf5 ,: <;._3 inf5
0 1 2 3 4 5
0 1 2 3 4 4

I'm pretty sure that \ is right and ;._3 is wrong, but not positive. Just as \ is a sliding window across one dimension, so ;._3 is a sliding window across any number of dimensions. But when that number is 1, its results should agree with \ . No?

-- DanBron 2007-01-06 04:23:27


crash on linear display of reassigment

The following sentences crash J: 

    9!:3[5
    r=.2.5
   (r=.2.5) ] *&r

I believe the requirements for this crash are:

  1. The sentence must contain a re-assignment of a noun to a verb or a floating point, literal, or boxed value, where the boxes (recursively?) contain floating point or literal values.

    1. The original datatype of the noun is irrelevant.
  2. The sentence must refer at least once to each of its original and new values.

    1. I think this means the name must be mentioned to the right of its re-assignment, at least once.

  3. The (verb?) result of the sentence must be displayed (in linear form).
    1. If the sentence is assigned to a name or the display is otherwise suppressed, there is no crash (even if the result of the sentence is displayed later).

    2. When the sentence is displayed, 5 e. 9!:2'' must be true.

Applies to ( 'j601/2006-11-17/17:05';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested)

-- DanBron 2007-11-09 21:37:39


crash on f. while suspended

The following lines will crash J: 

   sr           =:  1 : 'u y'
   13!:0]1
   13!:8]12
|assertion failure
|       13!:8]12
|[-0] 
   (+ sr        ) f.       NB.  J crashes here

The crash requires that the operator (either adverb or conjunction) mention both its own arguments and the arguments of its derived entity. That is, it must mention at least one of the names in each of the sets u v m n and x y.

More specifically, I believe it has derive one of those 'pending verbs' that J doesn't know what to do with until it is called with arguments (i.e. where the display of the verb contains the explicit definition of the operator and the linear representation of the argument(s) to the operator).

The crash only occurs if J is suspended.

The crash also appears dependent on the specific name of the operator. Certain names cause crashes, while others just prematurely return to immediate execution: 

   anOperator   =:  1 : 'u y'
   13!:0]1
   13!:8]12
|assertion failure
|       13!:8]12
   (+ anOperator) f.       NB.  No crash


   a =. (+ anOperator) f.  
   a                       NB.  pretix
|value error: a

Note that the only difference in the code for the crash vs the pretix is the name of the operator.

-- DanBron 2007-02-06 16:59:56


13&:'s result different from 4&:

  s=:' (r # x) ,. (r=. x -.@= y) # y'
  fi=:13 : s
  fe=: 4 : s
  1 3 2 3 fi 4 3 5 3   NB. Bug
1 1
2 2
  1 3 2 3 fe 4 3 5 3   NB. Correct
1 4
2 5

-- JuneKim 2007-02-09 01:27:15


bugs in fixing hybrid tacit/explicit self-referential verbs (in anonymous definitions)

There is a slight bug in J6's new method of isolating the context of $: when fixing verbs.

Verbs derived from f. are erroneous when:

  1. The argument contains an anonymous expression using:
  2. a named verb which itself:

  3. mixes self reference (with $:) and a multi-line explicit verb (commonly, to default one of the arguments to that explicit verb).

I have not investigated whether it is possible to generalize or further restrict these criteria.

Example: 

   dyadic      =: 4 : 0
this is my verb
with multiple lines
)
   ambivalent  =: ($:~ 0:) : dyadic

   (ambivalent ]) f.
4 : 0 ]
x ($:~ 0:) :(4 : 0)
this is my verb
with multiple lines
) y
)

Note that f. attempts to nest one multi-line explicit definition within another, resulting in syntax errors like ) y and pending explicit definitions like : 0 (which J will attempt to read from the keyboard when the verb is invoked). For example: 

   dyadic      =: 4 : ('z=.x+y';'2*z')
   ambivalent  =: ($:~ 0:) : dyadic
   fixed       =: (ambivalent +:) f.
   
   fixed 10
J is asking me to give
the defintion of the (incorrectly) nested explicit definition
but the invocation will choke on regardless of what I type.
)

The error results from a bug in how f. attempts to isolate the context of $:; it does not handle multi-line definitions properly.

The bug would be fixed if the erroneous nesting were replaced by the linear representation of the text of the definition, enclosed in parentheses. For example, a correct formulation of the above would be: 

   ] text =. (a:,1;1;1) {:: 5!:1{.;:'dyadic'
z=.x+y
2*z   

   5!:5{.;:'text'
2 6$'z=.x+y2*z   '
   
   fixed =: 4 : 0 +:
x ($:~ 0:) : (4 : (2 6$'z=.x+y2*z   ')) y
)

   fixed 10
60

Other single-line definition formats amenable to : might result in more readable code (if that is relevant for the normally-unscrutinized result of f.). E.G., one might prefer 'z=.x+y';'2*z' to the lrep in the preceding.

-- DanBron 2007-04-02 18:48:20


final sentence of f. specification incorrect

The sentence x f. will not fix any part of x that contains $: from the Vocabulary page for f. (1770 100 qdoj 'f.'), added in J5, should be removed for J6. It is now incorrect: 

   z =. $:@:<:^:*
   x =. 10 + z
   x f.
10 + 3 : '$:@:<:^:* y' :(4 : 'x $:@:<:^:* y')

Also, the notation x for an adverb's argument is outdated. The notation is now u, which can be a noun or verb (as x, above, may be noun or verb).

-- DanBron 2007-04-03 16:03:52


dyads #. and #: sensitive to type of empty RHA

Even though ''-:i.0, the dyads #. and #: treat them differently: 

   0 #. i.0
0
   0 #. ''
|domain error
|   0    #.''


   $ (,0) #: ''
0
   $ (,0) #: i. 0
0 1

Also, given that r&#: is defined in terms of r&#., and (,0)&#. i.0 signals error (fundamentally, because (,1) * i.0 signals error), perhaps (,0)&#: i.0 should too? Or maybe the other way around: maybe (,0)&#. i.0 should produce a result?

-- DanBron 2007-04-03 16:04:29


incorrect and inconsistent constant notation

I don't have time right now to make a full report. Here is a sample of the issue: 

   1E3        NB.  Not sanctioned in dictionary/dcons.htm
1000

   1D3        NB.  Ditto
1000

   1d3        NB.  Ditto
1000

   1.2r3.4    NB.  Ditto
0.352941

   0b6        NB.  Bug?  Single digits in zero base would still be zero, right? 
6
   0b66       NB.  _Has_ to be zero
6
   
   _b1        NB.  Same issue: should be infinite, no?
1
   _b11       NB.  Correct
_
   
   __b5       NB.  Same issue.
5
      
   _b_        NB.  Definite bug.
0
   _x_        NB.  Ditto
0
   3x_        NB.  Ditto.
0

I will try to come back later with a more formal, precise bug report. Otherwise, I hope this is enough information to effect an investigation.

-- DanBron 2007-04-11 22:31:49

explicit operators don't recognize derived verb arguments in locatives

Explicit operators do not derive explicit verbs when all references to the explicit verb arguments are in locatives: 

   'X Y'     =: 18!:3&.>2#a:
   
   qty__Y    =:  10 ?. 500
   price__X  =:  1000   %~ 10 ?. 1000
   tax_rate  =:  7e_2 4e_2 0 {~ (H 'NY NJ' ) i. {.@H=. 6 s: [: s: ;:^:(0 = L.)

   (- (tax_rate 'NY')&*)  price__X * qty__Y
19.8239 85.4744 192.351 14.6429 123.976 225.735 131.781 8.48904 52.8984 6.35376

   sales =: adverb define
:
       (- (tax_rate m)&*)  price__x * qty__y
) 

   X 'NY' sales Y
|domain error: sales
|   X    'NY'sales Y

   'NY' sales 
|domain error: sales
|       'NY'sales

So the operator is required to mention the explicit verb arguments outside of a locative at least once, even if the mention is useless: 

   sales =: adverb define
:
       x
       (- (tax_rate m)&*)  price__x * qty__y
) 

   X 'NY' sales Y
19.8239 85.4744 192.351 14.6429 123.976 225.735 131.781 8.48904 52.8984 6.35376

Raul Miller also encountered this problem; see the first line of his adverb in the SQL equivalent of a J function thread on the Forums.

Applies to ( 'j601/2006-11-17/17:05';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested. But obviously it was introduced when the explicit names changed)

-- DanBron 2007-04-14 13:55:32

security level out of date

The foreign 9!:25, security level, is out of date. The Dictionary page for 9!: says (4495 586 qdoj 'dx009') :

The errors are:

  1. There are no dyads 0!:n, and the monads 0!:n are not prohibited. (One can load a file from the filesystem using 0!:0<fn; though, nicely, one cannot display the contents of a file with 0!:011<fn.)

  2. The are 1!:n foreigns which are not dyads but are prohibited; notably, 1!:1.

  3. Moreover, the foreigns 1!:40, 1!:41, 1!:42 and (family) 16!:, don't exist. OTOH the foriegns 1!:43, 1!:44, 1!:45, and family 15!: do exist, and are not prohibited by security level (except for the 15!: family, which is).

  4. The wd commands are not prohibited (that is, the J engine still sends 11!:0 requests to the front end). Try 11!:0'qwd'[9!:25[1 in j.exe . Worse, try 11!:0 'wd winexec * DEL /F /Q some_important_file.

Analogous wording for current version of J:

But even this language leaves something to be desired. J programmers may have more security concerns than it covers.

At the simplest, you might also consider prohibiting 0!:n entirely, and the entire 1!: family, including 43+i.3. The former allows one to read files from the host, and the latter provides potentially sensitive information about its structure. (Besides, why should a restricted user be allowed to change the working directory)?

For a more comprehensive solution, please see my custom security level request.

Applies to ( 'j601/2006-11-17/17:05';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-04-17 22:33:05

fixed verbs broken

Similar to the bug in fixing hybrid verbs, there's another bug in f. wrt $:: 

   dyd =. [ $: ] 
   bob =. 'x' dyd ]
   bob f.
'x' 4 : 'x [ $: ] y' ]

The fixed form of bob should have parenthesis around the verb within the explicit definition, like so: 

'x' 4 : 'x([ $: ])y' ]

The problem is the original dyd is defined with a train of verbs, but its fixed counterpart is not.

Applies to ( 'j601/2006-11-17/17:05';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-05-22 18:09:52

crash on take with rational args

The sentence {./ 3 1r2 crashes J. But the bug is in dyad {. not monad {./, because J will also crash on these sentences: 

   'x y'=. 3 1r2
   x {. y

The symptom appears to be that the sentence x {. y will crash J when both x and y are rational and y<1.

Applies to ( 'j601/2006-11-17/17:05';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-05-23 17:02:39

Rank Basic Wrong

   i."_1 b.0
_ _ _

   (i."_ -: i."_1) 2 3
0

-- Raul Miller 2007-06-22 22:58:07

sparse of empty prefix crashes

As reported by Devon in the Forums the phrase $.\i.0 will crash J. I note that the crash is dependent upon the type of the empty array, as $.\'' does not crash.

Applies to ( 'j601/2006-11-17/17:05';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-09-25 19:56:21

definition of monad ". unclear

The Dictionary page for ". says (1298 234 qdoj '".'):

However, I can think of three cases where the clause I emphasized applies:

  1. 0-:#y or

  2. ".y results in an error or

  3. ".y causes a pretix.

However, for the latter two cases, the result of ".y is not as described (it is as the result of a simple execution of y).

I think the language should be clarified: it took me a while to recognize that the clause was trying to describe the behavior of ".''. You could replace the clause in question with "if 0=#y".

If that is insufficient to cover all the cases intended by the present language, the others should be made clearer, as should the handling of case B (and possibly case C, if ". could reasonably be expected to place something on the stack). I note that monadic ". is rank 1 (i.e. 1-:{.".b.0), so the suggested replacement suffices for all empty arrays, and more complex rank comparisons are unneccesary.

As a nice side-effect, the new language would distinguish "no execution result" from the cases where:

  1. ".y results in an empty noun (either 0-:#$".y or more generally 0 e.$".y) and

  2. an explicit verb which executes 0 non-test blocks (e.g. 3 :'assert. y'1) and

  3. maybe the difference in display in immex between sentence and name=.sentence.

which tend to confuse newbies (particularly case D). Since this effect is emergent (rather than specified), it does not conflict with the DoJ's philosophy of avoiding language merely used to avoid this type of confusion.

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-10-24 16:44:03

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-10-25 12:17:26

cannot exclude index from scalar

Even though it is possible to select indices from a scalar, as in 0{9 and _1{9, it is not possible to except (suppress) indices from a scalar: 

   (<<<0) { 9
|length error
|   (<<<0)    {9

   (<<<_1) { 9
|length error
|   (<<<_1)    {9

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-10-26 18:33:15

crash on monadic amend of boxed jmf

The following sentences will crash J: 

   load 'jmf'

   fn =. jpath '~temp\crash.jmf'
   createjmf_jmf_ fn;1e4

   map_jmf_ 'F';fn

   F  =:  ;:'one two three'
   F  =:  0 1 0} F ,: ;: 'uno dos tres'

Similarly for non-boolean m: 

   F  =:  0 2 1} F , 'uno dos tres' ,:&;: 'eins zwei drei'

The corresponding dyadic amendations do not crash (and may serve as a workaround): 

   F  =:  (i{       z) (i=.I.          0 1 0)} F [ z=.;: 'uno dos tres'
   F  =:  (i{idx}a:,z) (i=.I.0~:idx=.  0 2 1)} F [ z=.   'uno dos tres' ,:&;: 'eins zwei drei'

Which may indicate that this is a conflict between JMF and special code for item amend (though I'm not positiive the sentences above trigger the special code; though I checked that the crashes still occur even if all nouns are assigned on separate lines; that is, F=: c}F,:y and F=:c}F,y0,:y1).

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-11-02 17:37:25

fsm corrupts memory

As reported by RE Boss in the Forums, the following sentences, adapted from HenryRich's JfC, crash J: 

   m =. a. e. '0x123456789abcdefABCDEF'
   m =. m + a. e. '0x'
   m =. m + a. e. '0'
   
   s =. 1 4 2 $ 0 0 0 0 0 0 1 1
   s =. s , 4 2 $ 0 0 0 0 2 0 0 0
   s =. s , 4 2 $ 0 0 3 0 0 0 3 0
   s =. s , 4 2 $ 0 3 3 0 0 3 3 0
   
   1!:2&2 (5;s;m;0 _1 0 0) ;: 'qqq0x30x30x40x0x34a'

However, the problem is more complex; you may see the details in my Forum message.

Since this code is highlighted in book popular with J neophytes, it might be given some priority (lest they give up on J when they execute it and the interpreter crashes).

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-11-07 13:47:42

rank with more than three numbers

The following gives a length error: 

   0"0 0 0 0 ] 0

I belive it should just give 0 just like 0"0 0 0 ] 0, because according to the dictionary definition of m"n, "The rank used is 3 $&.|. n ." (It might be better to change the dictionary definition to reflect this.)

The same is true for ranking a verb: ]"0 0 0 0 ] 0 gives a length error, while it should return 0.

I'm using j601/2006-09-04/09:20 on i686-linux. -- BJonas 2007-11-08 11:01:08

long train crash

J will crash when it attempts to build a long train. For example, any of the sentences a=.(139792$-`-)`:6, (419382$'-') 128!:2 'a' or ".'a=.',139788$'-' will crash J. In each case, if you decrement the large integer, J will not crash.

Note that the second example makes it obvious that the building of the verb, not execution of it, causes the crash (the absence of a domain error for -'a' indicates this; shorter trains do produce that error). The assignments in the other two examples are only merely to prevent J from (trying to) display the verb and getting an out of memory exception before it can crash.

I think these examples indicate the bug is in the maximum depth of J's parse tree. If that's the case, then a limit or stack error is preferred, as in the cases + 1 :(}:^:('@'-:{:)65535$'-@') and (39998$'-') 128!:2 'a' respectively.

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-11-15 20:07:44

deep conversion crash

While trying to work around the train length limitation reported earlier, I came across the crash demonstrated below. I basically manipulate 3!:1-style strings to create a very long train; when I subsequently use 3!:2 to convert the string into an atomic representation, the interpreter crashes.

Since I am using 3!:2 on a string not directly the result of 3!:1, I am not certain that this is a bug in the interpreter. OTOH: since is the atomic rep of a repetitive train, it is self-similar (i.e. it has a recursive structure). I can apply 3!:2 successfully to any string which is a precursor to the one which crashes; there's nothing special about the "last one". The string is merely longer, representing a deeper object (though maybe my pointers are out of bounds?).

Since the crash occurs before I get a chance to apply 5!:0 to the atomic rep, I don't believe it is the same as the "train crash". But I cannot verify that it is 3!:2, and not the (deeply nested) boxed structure itself which is the problem, as attempts to directly generate the structure in J are frustrated by system limitations (e.g. "out of memory" errors).

Here is the verb that crashes: 

   tn  =: 4 : 0
   NB.!  Not general.

        H =. 176
        J =. H -~ # T =. 3!:1 y

        I =. 156 + +/\  0 4 8   4
        D =.           30 1 1 _17
        j =. 0.5

        for. i. x do.

            f     =. H }.T

            i     =. I + J * j =. +: j
            t     =. a.{~D + a.i. i{T

            T     =. t i}T
            T     =. T,f

        end.

        T
)

Here is a demonstration that it works correctly:

   seed =. - - - - -
   S    =: {. 5!:1 seed`''

   (3!:2 ] 0 tn S) 5!:0
- - - - -
   (3!:2 ] 1 tn S) 5!:0
- - - - - - -
   (3!:2 ] 2 tn S) 5!:0
- - - - - - - - - - -
   (3!:2 ] 3 tn S) 5!:0
- - - - - - - - - - - - - - - - - - -
   (3!:2 ] 4 tn S) 5!:0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   NB.  Etc

   S15 =: 15 tn S      NB.  Executes properly, returning a  3!:1
   s15 =: 3!:2 S15     NB.  Convert to atomic rep
   v15 =. s15 5!:0     NB.  Evoke atomic rep
   4!:0 v15`''         NB.  It's a proper train (of about  2^16  verbs).
3

and here is how to use it to make J crash: 

   S16 =: 16 tn S      NB.  Executes properly, returning a  3!:1
   s16 =: 3!:2 S16     NB.  J crashes here.  Can't convert to atomic rep.

I've had it crash on the argument 15 as well (but never on an argument of 14 or less). The problem may be related to available system memory (I don't think it has to do with the magic number 16, but I could be wrong).

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-11-15 21:13:47

define is permissive

The adverb 5!:0 is permissive; it will accept arguments encoded in a non-5!:1 format. Specifically, it permits excessive boxing: 

   (< (,'3') ; < (;:'--') ,<^:1 (,'3'); <;:'---')5!:0
- - - - -
   (< (,'3') ; < (;:'--') ,<^:2 (,'3'); <;:'---')5!:0
- - - - -
   (< (,'3') ; < (;:'--') ,<^:3 (,'3'); <;:'---')5!:0
- - - - -

The definition of 5!:1 does not allow for this extra depth (1565 194 qdojH 'dx005'):

Though I suppose that since 5!:0 is defined (ibid) as the inverse of 5!:1, and not the other way around (1280 78 qdoj 'dx005'):

the definition of 5!:0 could be considered incomplete rather than incorrect.

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-11-15 21:34:43

gerund referent not evoked

The Dictionary page for copula says If the character list begins with ` then gerund referents are evoked. (2052 87 qdoj '=:').

And while the interpreter honors this statement for gerund referents with 1 < # : 

   '`a b c'=.+`-`*  
   4!:0;:'a b c'
3 3 3
   
   '`a b'=.+`-
   4!:0;:'a b'
3 3

It does not for assignments from gerunds of length one: 

   '`a'=.+`'' 
   4!:0;:'a'
0

That is, the following is inconsistent: 

   evg =: 3 : 0
        N=. , a. {~32 ,.~ 97 + i. # y
        ('`',N)=.y
        *./ 3 = 4!:0 ;: N
)
   evg\. +`-`*`%`^
1 1 1 1 0

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-11-15 21:44:55

dictionary defn for floor does not handle tolerance

The dictionary definition of monad <. (Floor) claims:

However, when tolerance comes in, floor doesn't always return the same as <.. Here's an example with the default tolerance: 

      9!:18 ''
5.68434e_14
      floor=: j./@(ip+(c2>c1),c1+:c2)
      '`c1 c2 fp ip'=:(1:>+/@fp)`(>:/@fp)`(+.-ip)`(<.@+.)
      t =: 2j2 - 1e_13
      ($ ; <. ; floor) t
++---+---+
||1j2|2j2|
++---+---+

This is j601/2006-09-04/09:20 on linux-i686.

-- BJonas 2007-11-18 15:59:20

Extending the above, the value of floor sometimes depends on the internal type of a number. 

   <.x0 =: _1e_14
_1
   <.x1 =: _1e_14 j. 0
0
   x0 =!.0 x1
1

I request that you document the precise behaviour of tolerant floor on complex numbers, and implement it consistently.

-- BJonas 2010-02-09 22:04:26

tall stack crash

The following crashes J: 

   p=: 3 : 0
        m=.(3 #:@:+ [: i.@<:&.-: 2^#) y
        c=.m <@:p;.2"1 y
)
   
   p;:'a b c'

I believe this is an instance of the recursion limit bug. I'm aware that J6.01 eased this problem, but that some vestiges remain and are difficult to address.

OTOH, the nature of the bug makes examples hard to minimize, so I'll report it anyway, in case the bug is novel or unique.

A few things I did notice:

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-11-19 14:54:33

local/global nameclass confusion

Due to the situation described in an earlier bug report, explicit operators can return "confused" entities. For example: 

   z =. 'some noun'
   +1 :('z =. some verb or other';'z')
'some noun'
   NB.  Note the quotes around the display 
   
   e =. +1 :('z =. some verb or other';'z')
   4!:0 {.;:'e'  
3
   NB.  The result is a _verb_ 
   
   e f.  
|domain error
|       e f.
   e 4

|domain error: z
|       e 4
   NB.  But not really.

These confused names take their nameclass from their local context, but their value (later) from the global context.

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-11-19 20:25:35

equalty too tolerant for complex numbers

The verb = seems to use a wrong tolerance for complex numbers as for real numbers. This results in real and complex numbers being compared for equalty differently: 

   9!:18''
5.68434e_14
   tc =: 1+9e_14j1e_14-0j1e_14
   tr =: 1+9e_14
   tr =!.0 tc
1
   1 = tr
0
   1 = tc
1

The last result is agains the dict definition of =:

For a graphical demonstration, try 

   1=1+j./~1e_14*(i:15)
   1=1+1e_14*(i:15)

Using j601/2006-09-04/09:20 on i686-linux.

-- BJonas 2007-11-20 13:03:13

inverting hook recursion

Not sure this is a bug, but the final sentence here: 

   U =: * >: :.L
   L =: * <: :.U

   U b. _1
|out of memory
|       U b._1

Hangs J until it runs out of memory. It appears that the sentence is recursive; for some reason, requesting for the inverse of U requests the inverse of L, which in turn requests the inverse of U, ad infinitum. I only discovered this bug through a typo, and I don't know what the definition of f (g :. h) ^:_1, but it's not clear why it should inspect the value of h (is it trying to f. for some reason?).

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-11-30 14:45:46

too many digits from base representation

Similar to a bug Raul reported previously, the dyad #.^:_1 can produce leading zeros. For example: 

   10 #.^:_1 <:1e12
0 9 9 9 9 9 9 9 9 9 9 9 9

This boils down to a tolerance issue in monad <. which BJonas reported in the Forums. I am too ignorant of tolerance to know whether that behavior is itself a bug, but you may find some details in my followup message.

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2007-11-30 15:17:43

identity improperly optimized

The results of the following two sentences should be the same. They are not: 

   (i. 10) 4 :'x'"0  i. 10 10
0 0 0 0 0 0 0 0 0 0
1 1 1 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2 2 2
3 3 3 3 3 3 3 3 3 3
4 4 4 4 4 4 4 4 4 4
5 5 5 5 5 5 5 5 5 5
6 6 6 6 6 6 6 6 6 6
7 7 7 7 7 7 7 7 7 7
8 8 8 8 8 8 8 8 8 8
9 9 9 9 9 9 9 9 9 9

   (i. 10)      ["0  i. 10 10
0 1 2 3 4 5 6 7 8 9

The latter result is erroneous (and the question is not academic).

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2008-01-20 04:44:27

specification of verbal amend incomplete

The specification for verbal amend, u}, is incomplete (or misleading, or incorrect). The wording:

implies that x u y} and x (x u y)} y are equivalent. They are not; the former amends indices of the ravel of y. For example: 

   '*' 1 } 2 2 $'x'
xx
**
   '*' 1:} 2 2 $'x'
x*
xx

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2008-01-23 00:23:52

first use of adverb fails

Continuing the display of bonded conjunctions bug report, some bonded conjunctions produce spurious errors when invoked the first (but no subsequent) time.

For example: 

   a=:`(;:'@:"0')

   a               NB.  Previously-reported bug re: displaying bonded conjs
|domain error

   + a             NB.  Spurious error on first invocation
|domain error: a
|       +a
   + a             NB.  Subsequent invocations OK
+-+--+-+-+
|+|@:|"|0|
+-+--+-+-+

Applies to ('j602/2008-03-03/16:45';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2008-06-21 00:52:55

uninvestigated display crash

I encountered a crash today. You can reproduce it with this script. I will investigate further later; I am leaving this report as a reminder to myself, and so that you may investigate independently (if you choose).

I believe the bug is in the display of the resulting array, because J will not crash if the script to is modified by replacing the ultimate smoutput ... with A=: ... .

Applies to ('j602/2008-03-03/16:45';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2008-07-15 20:42:09

ambivalent verbs improperly fixed

The domain errors at the end of this example are spurious, and caused by a bug in f.: 

   defaultLHA =: 99&$: : [ 

   defaultLHA 9
99
   12 defaultLHA 9
12
   iLike42 =: 42&defaultLHA 

   iLike42 78
42

   12 iLike42 78
42
   
   iLike42 f. 78
|domain error
|       iLike42 f.78

   12 iLike42 f. 78
|domain error
|   12     iLike42 f.78

The problem is how f. fixes iLike42:

   iLike42 f. 
42&(3 : '99&$: :[ y')

Note that the original verb was ambivalent, but f. has constrained it to a monad. The proper fix would be 42 & (3 : '(99&$: :[) y') : (4 : 'x (99&$: : [) y'), or something similar.

I'm not sure what relationship this bug has to the bug in fixing hybrid verbs or the fixed verbs broken report.

Applies to ('j602/2008-03-03/16:45';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2008-07-30 14:35:34

Secondary problem

-- Raul Miller 2008-08-20 23:05:20

Explicit to tacit conversion problem

Conversion is wrong on explicit reflexive verbs, for example: 

   13 :'y*y'
*

-- JohnRandall 2008-09-29 18:32:55

sparse polynomial crash

J crashes when dyad p. is supplied a sparse argument. For example, the following sentences crash J:

NB.  Large sparsely populated integer array
D  =:  (1+?138#100) (($A) <@#: ?. 138 # */$A)}A=:400 400 $ {.0 2

NB.  Sparse-array equivalent
S  =: $. A

NB.  Polynomial application
S p. 12     NB.  J crashes here

J also crashes if the arguments to p. are reversed. However, no crash occurs if D is substituted for S (i.e. if both arguments are dense).

Applies to ('j602/2008-03-03/16:45';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2008-11-05 14:10:47

extended root error

The phrase _2%:2x produces a (weird) error:

   _2%:2x
|

Note no error message is produced. Investigating this, I notice:

   13!:11''   NB.  Error number
53

I'm not sure what that means, though. The only time I've seen an error number > 50 is in the throw. case.

Applies to ('j602/2008-03-03/16:45';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2009-06-19 17:01:22

nan won't do

The phrase _. ". 'r' crashes J. Neither _. ". 'q' nor _. ". 's' crashed J.

Applies to ('j602/2008-03-03/16:45';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.) * Devon corroborated.

-- DanBron 2009-08-17 02:47:07

stacking the proverbial deck

As previously reported by HenryRich, If "proverb" means "a name that stands for a verb", then this behavior 

           deck =. /
           deck deck
        deck deck

disagrees with Dictionary §II.E: 

   Parsing proceeds by moving successive elements (or 
   their values except in the case of proverbs and names 
   immediately to the left of a copula)

because named adverbs should be stacked (passed) by value.

AFAICT, §II requires proverbs to refer to verbs: 

    The name "area" thus assigned is a /pronoun/ and, as in 
    English, it plays the role of a noun. Similar remarks 
    apply to names assigned to verbs, adverbs, and conjunctions.

For a longer discussion of this topic, see "stacked by name" thread in the Forums. In particular, see the linked references.

If proverbs must be verbs, then the discrepancy can be resolved emending the DoJ (to say something like "except in the case of names to the left of copulae or which don't refer to nouns") or the implementation (by making pro-advs and pro-conjs stack by value, which I don't think would hurt many existing J users). I posted a fuller proposal in the Forums.

If this is not a bug, I'd like to know why.

Applies to ('j602/2008-03-03/16:45';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- DanBron 2009-08-17 03:09:00

128!:5] 0j_.

As mentioned in this mailing list thread, 128!:5] 0j_. gives 0 whereas I think it should return 1. The dictionary definition does not mention complex numbers, but I think any complex number whose real part or imaginary part is a nan should count as containing a nan. I could reproduce this bug in j602/2008-03-03/16:45 x86 linux, and also the 64-bit j602/2008-03-03/16:45 on amd64 linux. -- BJonas 2009-12-01 23:30:32

Dictionary 6!:8 (Query Clock Frequency)

The dictionary for j602 claims that 6!:8 y ignores its argument y, whereas actually it does not. The call 6!:8 $0 returns the clock divisor as claimed, whereas for example 6!:8 ]0 gives a rank error. The description of 6!:9, 6!:13 has the same problem. This applies to at least 64-bit j602/2008-03-03/16:45 on linux-amd64. -- BJonas 2010-02-05 21:21:31

Strange evoke of invalid gerund with fit

Evoking an atomic form of an errornous application of the fit conjunction seems to return a strange bonded conj adverb that is in no apparent relation with what we're intending to evoke. 

   (<'!.';<'?';<'0';0)@.0
!.0.622471467943081724
   (<'@';<'?';<'0';0)@.0
@0.324707122801778936
   a =: (<'!.';<'-';<'0';0)@.0
   a
!.0
   4!:0<'a'
1
   1 <a 1+1e_14
1

I believe that (<'!.';<'-';<'0';0)@.0 should either raise a domain error like -!.0 does, or give some other error, or possibly even return a verb of form -!.0 that always raises a domain error when called, but it definitely should not return an adverb.

This applies to at least 64-bit j602/2008-03-03/16:45 on linux-amd64.

-- BJonas 2010-02-21 23:43:26

System/Interpreter/Bugs (last edited 2010-02-21 23:43:26 by BJonas)