System/Interpreter/Bugs/Closed
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.
These reports/requests have been closed for the reason cited.
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 -:
-- Dan Bron <<DateTime(2005-11-09T21:14:49Z)>>
- I'm not sure that this is a bug. I think this behavior fits what the dictionary says about resolution for verbs: verbs are resolved as names, and the name is used at evaluation time to determine the context for execution. Here's a definition of evokeU that does what I think you want:
evokeU=:1 :'(5!:1<''u.'')5!:0'
-- ["Raul Miller"] DateTime(2006-05-22T19:39:30Z)
- I considered that interpretation. But I don't buy it (
pendantry ahead ).
-- Dan Bron <<DateTime(2006-05-22T21:15:36Z)>> - Related :
- Related :
sum_z_=:+/
({.;:'z') 1 : 'sum__m'
|value error: m
Of course, there's a work around `({.;:'z') 1 : ' (''sum_'',(;m),''_'')~ '` .
- You're stacking the explicit arguments names by value, aren't you? According to Section E of the Dictionary, which says "...their values except in the case of proverbs..." (3208 50 qdoj 'dicte'), this is a bug:
+ 1 : 0 u1 =. u / u =. * u2 =. u / (u1, u2) f. ) +/ , */ I don't want you to change this, but I wouldn't mind if the Dictionary were changed s.t. [wiki:JForum:beta/2006-April/000840 all local names were stacked by value].
Status: closed, documented in NuVoc. The original evokeU is not an error; 'u'~ evokes the name u which is returned as the result of the modifier; that gets a value error when used in the caller.
The special treatment of the local names x y u v m n is documented in the details of : .
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.
-- Dan Bron <<DateTime(2006-09-21T19:07:34Z)>>
Status: Closed, documented in NuVoc in the details of : .
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 ` .
-- Dan Bron <<DateTime(2006-12-30T18:22:14Z)
Status: Closed, documented in NuVoc. The error seems to be that gerund modifiers ` and `: cannot create a display when they have a boxed operand that is not a valid gerund.
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?
Status: closed, documented in NuVoc
-- Dan Bron <<DateTime(2007-01-06T04:23:27Z)>>
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).
Status: closed, documented in NuVoc
-- Dan Bron <<DateTime(2007-04-03T16:03:52Z)>>
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?
Status: closed, no problem. The behavior of #. is admissible (and now documented in NuVoc). The behavior of #: follows the rules for errors in fill-cells.
-- Dan Bron <<DateTime(2007-04-03T16:04:29Z)>>
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.)
-- Dan Bron <<DateTime(2007-10-26T18:33:15Z)>>
It seems you also cannot index a scalar (in its first dimension) if you use a boxed left argument: (<0) { 2 gives length error to me in j602/2008-03-03/16:45 amd64 linux.
Status: closed. { is not indexing an array, but conforming to the fact that an atom is considered to have one item.
-- User:B Jonas <<DateTime(2009-12-02T23:54:40+0200)>>
fsm corrupts memory
As reported by User:RE Boss in the Forums, the following sentences, adapted from HenryRich's [[JDic:../jforc/loopless_code_vii_sequential.htm#_Toc141158112|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.)
Status: closed, fixed in J8
-- Dan Bron <<DateTime(2007-11-07T13:47:42Z)>>
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. -- User:B Jonas <<DateTime(2007-11-08T11:01:08Z)>>
- These comments are also relevant for the definition of L: :
The full form of the levels used is 3$&.|.n. (1)
To be fair, the same page also says: It may have three elements, specifying levels for the monadic, left, and right cases (2)
But if that doesn't prohibit the case that 2-:#n then it cannot prohibit the case that 4-:#n. 1. 1500 63 qdoj 'L:' 1. 1408 86 qdoj 'L:'
Status: closed, documented in NuVoc
-- Dan Bron <<DateTime(2007-11-19T22:27:06Z)>>
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'):
The result is a single box containing a character list of the symbol (if primitive) or a two-element boxed list of the symbol and atomic representation of the arguments (if not primitive).
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'):
That is, (5!:1 <'f') 5!:0 equals f for all f.
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.)
-- Dan Bron <<DateTime(2007-11-15T21:34:43Z)>>
- There are other kinds of boxed nouns not returned by 5!:1 which 5!:0 accepts. Namely, you can use uv-style explicit adverbs in verbs, while 5!:1 only produces xyuv-style explicit adverbs, because uv-style explicit adverbs are already called by the time you run 5!:1. Try this for example (the 5!:0 produces a side-effect):
v =: [
a =: 1 :('1!:2&2''hello''';']')
vv =: 5!:1 <'v'
aa =: 5!:1 <'a'
ss =: <aa,<vv
s =: ss 5!:0
5!:1 <'s'
-- User:B Jonas <<DateTime(2007-11-16T14:37:16Z)>>
- I have probably misunderstood you, but I am not sure your example demonstrates what you think it does. In your code, ss is the internal representation of the train v a, not the internal representation of the gerund < aa,<vv. That is, (< aa,<vv) 5!:0 is identical to v a, which indeed produces the effects you note.
If you want 5!:0 to produce the gerund < aa,<vv you must pass it the atomic representation of that noun. To wit: (5!:1 {.;: 'ss') 5!:0.
You are correct that there are other kinds of nouns that 5!:1 will not produce, but 5!:0 will accept, and your ss is one of them. But I think trying the effect of evoking (invoking?) executable trains is "obvious". What I am concerned about in this bug report is the "unobvious" forms acceptable to 5!:0. Here's another example:
hi =. 'hello'
ars =. < '0' ; hi
arv =. < (,'0'); hi
ir =. 5!:1{.;:'hi'
ir -: arv
1
ir -: ars
0
arv 5!:0 -: ars 5!:0
1
But perhaps you're right; maybe "define" should not invoke trains, merely "single gerunds" (things producible with 5!:1) . Trains can already be invoked with `:6.
-- Dan Bron <<DateTime(2007-11-16T15:45:33Z)>>
- Further, despite the description of 5!:1 (quoted above), I know I've seen a case where the left-hand box was neither a single box nor two boxes where the left is a character list of a primitive or a code for a symbol-less entity. I've seen cases where the left hand box itself contains an atomic representation. I believe, but am less sure, I've also seen cases where the number of boxes was three. I cannot now think of examples, but will try to create some if requested (otherwise I'll just post them if I run across them).
Status: closed, left as undocumented feature
-- Dan Bron <<DateTime(2007-11-16T15:57:30Z)>>
dictionary defn for floor does not handle tolerance
The dictionary definition of monad <. (Floor) claims:
For a complex argument, the definition of <. is modelled by:
floor=: j./@(ip+(c2>c1),c1+:c2) '`c1 c2 fp ip'=:(1:>+/@fp)`(>:/@fp)`(+.-ip)`(<.@+.)
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.
-- User:B Jonas <<DateTime(2007-11-18T15:59:20Z)>>
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.
Status: closed, documented in NuVoc
-- User:B Jonas <<DateTime(2010-02-10T00:04:26+0200)>>
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.)
Status: closed, no problem. Any verb v can refer to other names, which were either defined as verbs or undefined when v was assigned. If these names are later redefined as non-verbs, the verb v becomes unusable, and an attempt to evaluate it creates a domain error.
-- Dan Bron <<DateTime(2007-11-19T20:25:35Z)>>
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 =:
If x or y is a finite floating-point or complex number, the comparison is made with a tolerance t , normally 2 to the power _44 but also controlled by the fit conjunction !. , as in x=!.0 y . Formally, x=y is 1 if the magnitude of x-y does not exceed t times the larger of the magnitudes of x and y .
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.
-- User:B Jonas <<DateTime(2007-11-20T13:03:13Z)>>
The bug doesn't seem to happen with j602/2008-03-03/16:45 i686-linux.
Status: closed, fixed in J6.02
-- User:B Jonas <<DateTime(2008-03-20T11:06:03Z)>>
specification of verbal amend incomplete
The specification for verbal amend, u}, is incomplete (or misleading, or incorrect). The wording:
u} is defined in terms of the noun case m}
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.)
Status: closed. x u} y is deprecated.
Secondary problem
http://www.jsoftware.com/help/dictionary/intro28.htm
Ei=: i.@(+*+0&=) NB.Extended integers CPA=: (@])%.i.@#@]^/Ei@[ NB.Coeffs of poly approx (adverb) |syntax error
Status: closed, no problem. A V V V V V is not valid syntax.
-- User:Raul Miller <<DateTime(2008-08-20T23:05:20Z)>>
-- Dan Bron <<DateTime(2008-01-23T00:23:52Z)>>
nan won't do
The phrase _. ". 'r' crashes J. Neither _. ". 'q' nor _. ". 's' crashed J.
Status: closed, fixed in J8
-- Dan Bron <<DateTime(2009-08-16T23:47:07-0300)>>
stacking the proverbial deck
As previously reported by Henry Rich, If "proverb" means "a name that stands for a verb", then this behavior
deck =. / deck deck deck deck
disagrees with Dictionary §II.E:
#!quote 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:
#!quote
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.
Status: closed, documented in NuVoc. Only nouns are passed by reference, others by name.
-- Dan Bron <<DateTime(2009-08-17T00:09:00-0300)>>
128!:5] 0j_.
As mentioned in [[ http://jsoftware.com/pipermail/programming/2009-December/017068.html |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. -- User:B Jonas <<DateTime(2009-12-02T01:30:32+0200)>>
Apparently [[ http://jsoftware.com/pipermail/programming/2009-December/017095.html |the 128!:5 verb can even crash J in some cases if used on complex numbers]]. This might be related. -- User:B Jonas <<DateTime(2009-12-02T23:04:41+0200)>>
I cannot reproduce this bug in j64-701. -- User:B Jonas <<DateTime(2011-02-04T15:04:53+0200)>>
Status: closed, fixed in J8
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.
Status: closed, documented in NuVoc
-- User:B Jonas <<DateTime(2010-02-05T23:21:31+0200)>>
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.
-- User:B Jonas <<DateTime(2010-02-22T01:43:26+0200)>>
It seems that this bug is still present in j64-701. -- User:B Jonas <<DateTime(2011-02-04T15:04:53+0200)>>
Status: closed, no problem. It is good design for users of ARs to assume that they are well-formed, which puts the onus of the creator not to produce one that, as here, could not have been created using ` .
In Dictionary page for monad-dyad conj, example output wrong
On the j602 Dictionary page for the monad-dyad conjunction u :v (d310v), there is an example command where the output shown is a valence error error message, whereas currently that example gives domain error instead. Please fix the output so it corresponds to what the interpreter actually does. (Sorry for nitpicking.)
-- User:B Jonas <<DateTime(2010-08-26T01:03:12+0200)>>
Status: closed, documented in NuVoc
q: gives up for no good reason
q:12323x*12211x*12433x 12323 151819363 9!:14 '' j602/2008-03-03/16:45
-- Andrew Nikitin <<DateTime(2011-06-24T15:06:30-0400)>>
Status: closed, fixed in J8
conjunction (and adverb) defined in locale is not always executed within that locales context
bug exists in J7 and J8 64 bit windows. Most likely the error occurs when a modifier definition accesses y. This cannot be intentional design because one locale's definition cannot possibly rely on another locale's state, and the primary reason for defining a modifier in a specific locale is to use that locale's environment.
cocurrent 'myl' a=: 4 c =: 2 : 0 NB. will execute wrong (callers) locale smoutput 18!:5 '' u a v y ) cp =: 2 : 0 NB. will execute right (this) locale smoutput 18!:5 '' v@:u^:a ) cocurrent 'newl' c2_myl_ =: 2 : 0 smoutput 18!:5 '' u a v y ) test =: 3 : 0 a=: 14 smoutput >: c_myl_ + 1 smoutput >: c2_myl_ + 1 c =: conew 'myl' >: c2__c + 1 ) in session: test_newl_ '' NB. results should be 6 (and <'myl') for all 3. ┌────┐ │newl│ └────┘ 16 ┌────┐ │newl│ └────┘ 16 ┌────┐ │newl│ └────┘ 16 conjunction that does not access y in session (or script): conj_myl_=: 2 :'v@:u^:a' >: conj_myl_ ] 1 NB. result for both should be 5 5 >: cp_myl_ ] 1 5
Status: closed, no problem, the result of executing a modifier is not a locative
Release notes should mention NVV forks
The dictionary documents NVV forks, that is, trains of the form (n v w) where n is a noun, and v and w are verbs. However, these are a new feature and so should be mentioned in the release notes as well. -- User:B Jonas <<DateTime(2013-11-23T23:21:08+0200)>>
Status: closed, obsolete
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 User:B Jonas 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.)
Status: Closed, no fix. The number of digits is calculated as <. x ^. y, and with tolerance this can leave an extra digit. There is no way to make the logarithm accurate enough to get the number of digits right, so the only solution would be to try converting the maximum value and seeing how many digits are needed. Rather than incurring this overhead for every use, it will be left for the user to polish.
-- Dan Bron <<DateTime(2007-11-30T15:17:43Z)>>
In Dictionary page for tie, example verb `ar` wrong
On the j602 Dictionary page for the tie conjunction (d610), there's an example monadic verb called ar defined, that claims to give the atomic representation from a noun. The definition is wrong, it doesn't work for boxed nouns. Please fix this example or remove it. -- User:B Jonas <<DateTime(2010-08-26T01:03:12+0200)>>
Status: Documented in NuVoc page.
Expand 15!: in the Dictionary
The dictionary page for the 15!: foreign (native function call interface) is currently only a list that names the first few 15!: functions. It links to a User page that gives some more information. Even if the 15!: foreign isn't documented in the dictionary as completely as most other foreigns, it would be nice if at least all of its subfunctions would be listed. Specifically 15!:10 (get error code) is documented in User, and the module gives names to other verbs as well: 15!:5 (unload shared libary), 15!:6, 15!:7, 15!:8, 15!:9, 15!:11, 15!:13. -- User:B Jonas <<DateTime(2008-08-06T13:55:57Z)>>
(I forgot to add this was dictionary for j602 on x86 linux system.
-- User:B Jonas <<DateTime(2008-08-06T14:01:52Z)>>)
Status: closed. Foreigns page has been updated in NuVoc
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 [[JDic:../release/iamend|special code for item amend]] (though I'm not positive 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.)
Status: closed. Boxed mapped files no longer supported.
-- Dan Bron <<DateTime(2007-11-02T17:37:25Z)>>
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'):
non-unique sparse elements ($.i.4){i.4 2 the sparse element of a sparse array must be an atom
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.
Status: closed, no fix. When a verb is applied to a sparse array, it is applied separately to the sparse element and the individual nonempty values. The application of the verb to the sparse element must return a cell all of whose atoms are identical; the common value becomes the sparse element of the result. If there is no common value, 'non-unique sparse elements' is raised.
-- Dan Bron <<DateTime(2006-12-30T18:53:50Z)>>
Error in float representation between 1e15 and 1e19
should return float values for all cases Verified for J 8.05 and J 8.06:
JVERSION Engine: j806/j64avx/darwin Beta-4: commercial/2017-06-27T12:55:06 Library: 8.06.03 Qt IDE: 1.5.3/5.6.2 Platform: Darwin 64 Installer: J806 install InstallPath: /users/bobtherriault/j64-806 Contact: www.jsoftware.com (; datatype) 999999999999999.3 ┌────┬────────┐ │1e15│floating│ └────┴────────┘ (; datatype) 9999999999999999.3 ┌─────────────────┬───────┐ │10000000000000000│integer│ └─────────────────┴───────┘ (; datatype) 99999999999999999.3 ┌──────────────────┬───────┐ │100000000000000000│integer│ └──────────────────┴───────┘ (; datatype) 999999999999999999.3 ┌───────────────────┬───────┐ │1000000000000000000│integer│ └───────────────────┴───────┘ (; datatype) 9999999999999999999.3 ┌────┬────────┐ │1e19│floating│ └────┴────────┘
Status: closed, no fix. As a floating-point number limited to 15 digits of precision, 9999999999999999.3 has no fractional part. If the number cannot be represented as a floating-point value, it is better to represent it as an integer.
$.^:_1 d. 1 runs out of memory
-- Henry Rich <<DateTime(2014-04-19T15:49:56Z)>>
Status: Closed; calculus has been removed from the JE
p:^:_1 d. 1 runs out of memory
-- Henry Rich <<DateTime(2014-04-19T15:49:56Z)>>
Status: Closed; calculus has been removed from the JE
] d. (1 2,:3 4) 3 freezes
-- Henry Rich <<DateTime(2014-04-19T19:42:50Z)>>
Status: Closed; calculus has been removed from the JE
((5 &*) D.1 100) 10 crashes
Status: Closed; calculus has been removed from the JE
Henry Rich (talk) 20:29, 8 July 2018 (UTC) on behalf of Alec Newman
Higher derivatives inaccurate unless symbolic
0j13 ": sin d.3 (1) NB. The correct result, calculated symbolically _0.5403023058681 0j13 ": sin D.3 (1) NB. Approximation - way off! 111022.3024625156500 0j13 ": sin D. 1 D. 1 D. 1 (1) NB. Not as far off if done by hand _0.5352054832652 0j13 ": 1E_6 sin D:3 (1) NB. Error seems to be too small a step 111.0223024625157 0j13 ": 1E_4 sin D:3 (1) _0.5400124791777
-- Henry Rich <<DateTime(2014-04-19T21:17:40Z)>>
Status: Closed; calculus has been removed from the JE
Second partial derivatives wrong
func =: verb define NB. (x-2)^2 + (y-3)^2
'x y' =. y
(*: x-2) + (*: y-3)
)
]hessian =: func D. 2 (2 3) NB. Hessian at (2,3) - should be symmetric!
2 _0.5
0.333333 2
]hessian =: func D. 1 D. 1 (2 3) NB. better
2 _2.64698e_16
_8.82326e_17 2
-- Henry Rich <<DateTime(2014-04-19T21:17:40Z)>>
Status: Closed; calculus has been removed from the JE