System/Interpreter/Bugs/Errors

From J Wiki
< System‎ | Interpreter‎ | Bugs
Jump to navigation Jump to search
Requests: Interpreter   Bugs: Interpreter

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


The interpreter handles these scenarios incorrectly.


Errors in special code

,&.>/ y does scalar replication wrong

   ,&.>/ (i. 5);4;i. 2 3
+---------+
|0 1 2 3 4|
|4 4 4 4 4|
|0 1 2 0 0|
|3 4 5 0 0|
+---------+
   ,",&.>/ (i. 5);4;i. 2 3
+---------+
|0 1 2 3 4|
|4 4 4 0 0|
|0 1 2 0 0|
|3 4 5 0 0|
+---------+

The special code behaves more like ; , figuring out the shape of the result and replicating to the full result size

-- Henry Rich <<DateTime(2014-04-30T01:15:37Z)>>

Status: open

Bugs in 13 : and f.

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

Status: open

-- June Kim <<DateTime(2007-02-09T01:27:15Z)>>


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:

  • The argument contains an anonymous expression using:
  • a named verb which itself:
  • 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.

Status: open

-- Dan Bron <<DateTime(2007-04-02T18:48:20Z)>>


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

Status: open

-- Dan Bron <<DateTime(2008-07-30T14:35:34Z)>>


Bugs in Sparse Arrays

Error in sparse rank processing

   d=: (13 5 7?@$2)*13 5 7?@$5
   s=:(2;'')$.d
   rt =. ]
   rt"1 s
|non-unique sparse elements
|       rt"1 s

Using the name causes the rank processor to be used rather than the special code.

Status: open

Henry Rich (talk) 16:25, 19 June 2019 (UTC)


Error in sparse rank processing on cells that have no non-sparse values

   sa=. 1 (< 1 1)} 1 $. 2 2 ; 0 01 ; 00
   <@(4&$.)"1 sa
+-+
|1|
+-+
   NB. the result expected:
+-+-+
| |1|
+-+-+

Sparse rank, which uses a separate code path, does not execute the verb on cells that have no non-sparse values [1], [2].

References:

  1. [Jbeta] leading empty box is disappearing, Igor Zhuravlov, Thu Sep 9 07:40:06 UTC 2021
  2. GitHub issue #106, jip, Fri Sep 24 00:14:00 UTC 2021

Status: open

Igor Zhuravlov (talk) 23:33, 9 September 2021 (UTC)

Other errors

Debug does not suspend on value error

   cocurrent 'loc'
   dec=: ([ [: smoutput 'd:' , [: > coname@'')
   isboxed=: 32=3!:0
   enc=: 3 : ('smoutput ''e1:'',>coname$0';'1 enc y';':';'smoutput ''e2'':>coname$0';'isboxed y')
   cocurrent 'z'
   test=: enc_loc_ : enc_loc_ :. (1 1&dec_loc_ : dec_loc_)
   testi=: test_z_^:_1
   cocurrent 'base'
dbr 1
   0:&.testi ''

Should suspend on value error, but doesn't because the error is detected in unquote before dbunquote is called

Henry Rich (talk) 10:43, 30 September 2019 (UTC)


Odd behaviour in u : v versus suspension

Suspension with dbr 1 in u : v produces odd behaviour when a suspension occurs within explicitly-defined v.

This occurs in J8.07 and J901 beta-n:

   f=.     (4 : 'assert. 0 [ smoutput ''here''')
   g=. + : (4 : 'assert. 0 [ smoutput ''here''')
   dbr 1
   1 f 2
here
|assertion failure: f
|   0    [smoutput'here'
|f[:0]
      dbr 1

   1 g 2
here

   a=. 1 g 2
here
|assertion failure: g
|   0    [smoutput'here'
   NB. No suspension

Also notice that this seems to require the suspension happens directly within v, and not in a verb it calls. Compare with below, where f and g call assert rather than assert. .

Note in this cases the suspension occurs in both cases, but the line number reported in g appears always to be 0:

   f=.     (4 : ('smoutput ''line 0''';'assert 0[smoutput ''line 1'''))
   g=. + : (4 : ('smoutput ''line 0''';'assert 0[smoutput ''line 1'''))
   dbr 1
   1 f 2
line 0
line 1
|assertion failure: assert
|assert[0]
      13!:1 ''
|assertion failure
*assert[0]
|       assert 0[smoutput'line 1'
|f[:1]
|   1     f 2
      dbr 1
   1 g 2
line 0
line 1
|assertion failure: assert
|assert[0]
      13!:1 ''
|assertion failure
*assert[0]
|       assert 0[smoutput'line 1'
|g[:0]
|   1     g 2
   

Kirk Iverson (talk) 10:54, 1 November 2019 (UTC)


Obverse in Locale

Originally reported in [1]. Also discussed in [2]. Cross-referenced in [3]. New J9 features u. and v. doesn't help, too:

   cocurrent 'thing'
   Base=:     #.
   Antibase=: #:
   conj=:     2 : 'u. :. v.'
   verb2=:    Base conj Antibase
   cocurrent 'base'
   0 verb2_thing_ 0
0
   0 verb2_thing_^:_1: 0
|value error: Antibase
|   0     verb2_thing_^:_1:0

References:

  1. Jforum: Locale of Obverse, Mark D.Niemiec, Tue Sep 19 14:04:34 HKT 2000
  2. [Jprogramming] why won't this work (bug in :: ?), Pascal Jasmin, Sun Jun 22 02:29:49 UTC 2014
  3. GitHub issue #107, jip, Fri Sep 24 00:36 UTC 2021

-- Igor Zhuravlov (talk) 02:26, 28 January 2020 (UTC)

This is not an error, but it may be something that should be changed. The rule is that the locale changes when a locative is executed. verb2_thing_ is a locative, but verb2_thing_^:_1: is not.

-- Henry Rich (talk) 02:58, 28 January 2020 (UTC)