System/Interpreter/Bugs/Errors
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:
- ↑ [Jbeta] leading empty box is disappearing, Igor Zhuravlov, Thu Sep 9 07:40:06 UTC 2021
- ↑ 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:
- ↑ Jforum: Locale of Obverse, Mark D.Niemiec, Tue Sep 19 14:04:34 HKT 2000
- ↑ [Jprogramming] why won't this work (bug in :: ?), Pascal Jasmin, Sun Jun 22 02:29:49 UTC 2014
- ↑ 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)