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

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

Outstanding requests for J interpreter extensions and enhancements. (Library extensions and enhancements are on another page.)

Requests and responses in 2005, 2006, 2007.



{:: performance

Syntactically, {:: is a perfect choice for scattered indexing without boxing.

   A=: 100 100 ?@$ 100
   I=: 100000 2 ?@$ 100
   $(<"1 I){A
100000

   (I {:: A) -: (<"1 I){A
1

However, it does not perform very well compared to { with boxed argument, which could make it a candidate for special code.

   ts=: 6!:2 , 7!:2@]
   3 ts'I {:: A'
0.319013 6.26961e7
   3 ts'(<"1 I){A'
0.0432512 9.95654e6

Least memory is taken by such construst

   (I {:: A) -:  I (<@[ { ])"1 _ A
1
   3 ts'I (<@[ { ])"1 _ A'
0.241267 591872

-- OlegKobchenko 2006-01-18 19:00:23


make x&(#.^:_1) invertible

Please make the monad x&(#.^:_1) (and x #.^:_1 ], x #.^:_1 [, and any other likely forms) invertible:

   #.^:_1 b. _1
#.
   
   (44&#.)^:_1 b. _1
44&#.
   
   44&(#.^:_1) b. _1
|domain error
|       44&(#.^:_1)b._1

-- DanBron 2007-03-12 17:05:34

uncaught `throw.`

It turns out that uncaught throw. terminates execution with no message or other indication what is going on. it would be nicer if it said something, like error message.

-- AndrewNikitin 2007-09-06 17:07:27

case. 0 case. 1 do.

Currently, J's select. implementation requires that each case. be accompanied by a do. block. For some problem domains, it would make sense for multiple cases to share the same do. block. This could be supported with J's select. notation by allowing multiple case. entries next to each other followed by a single do. block. I ran across this today, trying to implement some support for dimensional analysis in J -- you need to deal with + and - in the same fashion.

-- Raul Miller 2007-10-24 13:22:26

   case =: 3 : 0
        select. y
                 case. 'joe';'john'   do. z=.'male'
                 case. 'jane';'jill'  do. z=.'female'
                fcase. 'fido';'rex'   do. z=.'not relevant'
                 case.                do. z=.'(unknown)',~".''' '',~z'
        end.
)
      
   (,. case&.>) ;:'joe john jill jane fido rex whiskers'
+--------+----------------------+
|joe     |male                  |
+--------+----------------------+
|john    |male                  |
+--------+----------------------+
|jill    |female                |
+--------+----------------------+
|jane    |female                |
+--------+----------------------+
|fido    |not relevant (unknown)|
+--------+----------------------+
|rex     |not relevant (unknown)|
+--------+----------------------+
|whiskers|(unknown)             |
+--------+----------------------+

   gtch  =:  3 : 0
        select. y 
                case. 0 do. goto_case1.   NB.  Considered harmful
                case. 1 do. label_case1. 'Judge not, lest ye be judged' 
        end.
)
|control error
|   [1]         case. 0 do. goto_case1.   NB.  Considered harmful
|   gtch=:    3 :0

reinstate <;.1^:_1

I observe:

   <;.1^:_1 <;.1  '/one/two'
|nonce error
|       <;.1^:_1<;.1'/one/two'

That is, the inverse of <;.1 is momentarily undefined. I request that the previous inverse, ;, be reinstated (at least under limited circumstances).

I know the general definition of x&(<;.1)^:_1 is a tricky problem. But I am not sure that it applies to the inverse of the monad, <;.1^:_1.

Even if the monad's inverse suffers from the same complications, there are simple cases where ; would suffice, and I request that they be implemented as such. The nonce error should be retained where ; is not obviously sufficient.

An example simple case is the above: a vector of boxes where each box contains a vector (I can't think of a case where <;.1 would produce boxed scalars, but perhaps the "simple case" could be generalized to include those, too).

If this proposal is adopted, I submit the parallel proposal that special code which supports phrases of the form: ;@:(<@:u;.1) be extended to support phrases of the form u&.>&.(<;.1).

These proposals apply to <;.2 as well as <;.1. They may also apply to the negative counterparts, <;._1 and <;._2, but that is less clear. For a fuller proposal on how to handle those inverses, see cut to fit

You may see the original request on the Forums, as well as an earlier inquiry.

-- DanBron 2007-10-30 14:32:26

cut to fit

Similar to an old request of mine, I propose an extension to ;..

The request is for a new application of !.. Fit should apply to monads derived from the cut conjunction such that:

   u;._1!.n  ↔   u;._1 @: (n&,)
   u;._2!.n  ↔   u;._2 @: (,&n)
   u;. 1!.n  ↔   u;. 1 @: (n&,)
   u;. 2!.n  ↔   u;. 2 @: (,&n)

and when u =: < then the respective inverses are:

   [: }.@:; n&,&.>
   [: }:@:; ,&n&.>
      }.@:;
      }:@:;

I'm not sure what do to for inverses of other u, as u^:_1 is probably not what's wanted. (For example, the inverse of < is > but what we want here is ; instead.)

However, that is not a large obstacle, because I think that:

   u&.>&.(<;.m!.n)

will mostly cover the ground. Given that, I believe the idiom should be given special consideration and be supported by special code.

The optimization would ideally apply for all u, but it should at least apply to all u which special code already supports in ;@:(<@:u;.1) (viz my previous request). Special code which supports the idioms <@:u;.m and u&.>@:(<;.m) might also be considered for extension.

Motivations and disincentives for implementing this proposal are as detailed in the original Forum message:

-- DanBron 2007-10-30 00:19:42

x and y in adverbs and conjunctions

   + 1 :'y' 0
|value error: y
|       y
   + 1 :'v=.y' 0
0

Could we at some point have an option to turn off the situational definition of x and y -- where x really means u and y really means v if neither u nor v are present?

-- Raul Miller 2007-11-05 22:06:46

verb pipelines

I request an extension to the conjunction `:; I would like to use it to produce verb pipelines. That is, I would like f0`f1`:1 to be equivalent to f0@:f1 , f0`f1`f2`:1 to be equivalent to f0@:f1@:f2 and so on.

The function code 1 is arbitrary and may be anything you like. But I suggest naming the code pipe (analogous to 6, train).

You might also consider another code, similar to the above, except the connecting conjunction is @ instead (I think of f@g@h as an assembly line, but the word assemble is loaded in J, so you might consider conveyor or something else suggestive).

Here is a model of the proposed extension:

   eg =: 2 : 0  NB. Evoke Gerund
        if. n e. 1 2 do.
                m =. }: , m ,. n { a: , ;:'@:@'
                m`:6
        else.
                m`:n
        end.
)

   f0`f1 eg 1
f0@:f1

   f0`f1`f2 eg 1
f0@:f1@:f2

   f0`f1 eg 2
f0@f1

I note that that `:6 accepts verb arguments, and treats them as length-one gerunds. If you wish to make `:1 consistent with that model, substitute ({.u`]) ,. for m ,..

-- DanBron 2007-12-21 21:32:32

rank of q:^:_1

I suggest the inverse of q: be */"1 rather than */. The monad q: produces rank-1 arrays of integers, so its inverse should apply to rank-1 arrays of integers.

In my post to the fitting factors thread in the Forums, you may see a concrete example of where the new inverse would be more succinct: I had to write &.(q:"1) rather than the shorter &.q:.

Like any other change, backwards compatibility must be considered, but I don't imagine this would break much code.

-- DanBron 2008-01-08 21:48:26


Dictionary page for Special Code nubbed

The Dictionary J601 Appendix "Special Code" has two copies of each of the following entries.

m&i.

monad

also m&i: -.&m e.&m ; see the J 5.04 release notes

;@:(<;.0)

dyad

special code; see the J 5.03 release notes

i.<./

monad

also i.>./ and i:<./ and i:>./ ; special code for integer and floating point lists (see the J 5.04 release notes)

x&(128!:3)

monad

special code to pre-compute look-up table of CRC values for each byte

It would be nice if one of these got deleted. Thanks.

-- BJonas 2008-02-01 08:10:35

P.S. Oh, and verify that they're really exact copies. I might have overlooked something.

make dyad ". invertible

I request that the dyad ". (numbers) be given an inverse. I propose the inverse be ": (as it is for monadic ".). A minor improvement would be to to use a hypen rather than an underbar for the negative sign.

I can't of a way to make the x in x&". useful to the inverse. One idea is to make x&".^:_1x&":, but the problem with that approach is that for most applications, x=0, yet 0&": is not a useful format (again, for most applications).

In any case, I see no reason why +:&(0&".) should fail (and its obvious substitute, +:&.". has wrong (and dangerous) semantics.

-- DanBron 2008-02-01 23:27:07

make tacit scalar replacement invertible

I request that the idiomatic verb =&m`(,:&n) }  for scalar m and n, be invertible. The inverse is =&n`(,:&m) } .

For example:

   in  =. =&'-'`(,:&'_') }
   out =. =&'_'`(,:&'-') }

   io  =. [: ". in :. out

   +:&.io '-1 2 3'
-2 4 6

could be rewritten more succinctly as:

    io =.  [: ". '-'&=`(,:&'_') }
    +:&.io '-1 2 3'
-2 4 6

This one new inverse would suffice for the majority of my use cases, but you may also consider making inverses for the verb's affilates.

That is, you could create the following mappings (or a subset thereof):

   = &m`(,:&n) } ^:_1  ↔  = &n`(,:&m) }   NB. A
   ~:&m`(n&,:) } ^:_1  ↔  ~:&n`(m&,:) }   NB. B
   m& =`(,:&n) } ^:_1  ↔  n& =`(,:&m) }   NB. C
   m&~:`(n&,:) } ^:_1  ↔  n&~:`(m&,:) }   NB. D

   = &m`(n&,:) } ^:_1  ↔  = &n`(m&,:) }   NB. E
   ~:&m`(,:&n) } ^:_1  ↔  ~:&m`(,:&m) }   NB. F
   m& =`(n&,:) } ^:_1  ↔  n& =`(m&,:) }   NB. G
   m&~:`(,:&n) } ^:_1  ↔  n&~:`(,:&m) }   NB. H

But I'm not convinced these extra inverses provide much value:

-- DanBron 2008-02-01 23:45:30

special code for tacit scalar replacement

I request that the idiomatic verbs m&=`(,:&n)}  and m&=`(n&,:)}  for scalar m and n and e.&m`(,:&n)}  and e.&m`(n&,:)}  for vector m and scalar n be supported by special code.

In particular, I am thinking of the special code which underlies c}x,:y for boolean c (that is, the special code for explicit monadic boolean amendment).

If my proposed inverses for scalar replacement are implemented, I submit the parrallel request that this special code support those inverses as well (which may just fall out natually, as the inverses have the same (optimizable) form).

In that previous request, I showed how the = verbs can be useful. Here is an example of the utility of the e. verbs:

   e.&WHITESPACE`(,:&' ')}  'stuff and',LF,'things',TAB,'some more'
stuff and things some more
   e.&DIGITS    `(' '&,:)} 'buy 123 of item 5'
    123         5

   ;: e.&WHITESPACE`(,:&' ')}  'stuff and',LF,'things',TAB,'some more'
+-----+---+------+----+----+
|stuff|and|things|some|more|
+-----+---+------+----+----+
   0 ". e.&DIGITS    `(' '&,:)} 'buy 123 of item 5'
123 5

-- DanBron 2008-02-02 00:29:14

redefine u;.0 y

Currently, the definition of monad cut-0 is (1224 143 qdoj ';.'):

I don't think this definition is very useful. I propose u;.0 y be redefined to mean "apply u along each axis of y", or, formally:

   u;.0 y  ↔  0&|:@:u^:(#@:$) y

Though backwards-incompatible, I believe the change is warranted. The question of "how do I apply a function to each axis of an array" arises perenially in the Forums. For example:

On the other hand, I do not see evidence that there is a frequent need to reverse an array along each axis. Further, code that does depend on the current definition of u;.0 y can readily be converted to use the new definition, simply by replacing u;.0 y with u |.;.0 y or (0 _1 */$y) u;.0 y or (-$y) u;.0 y; verb definitions that embed the monad u;.0 can be similarly converted by substituting @:(|.;.0) for ;.0.

As these substitutions show, the new definition is a generalization of the old, and is more in the spirit of ;. (in particular, and J in general).

-- DanBron 2008-06-20 19:24:51

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. -- BJonas 2008-08-06 13:55:57 (I forgot to add this was dictionary for j602 on x86 linux system. -- BJonas 2008-08-06 14:01:52)

Change ;: dyad

I would like to propose two changes for the ;: dyad.

My motivation in both cases is compactness and efficiency. Of course, we have other ways of reaching these results. We could, for example, re-implement ;: in J. However, ;: is useful because of its compactness and efficiency. The benefits would be visual, as well as mechanical (especially on 64 bit systems). I have attached a proposed update to the dictionary proposed-d332.htm. -- Raul Miller 2009-06-03 19:33:10

extend Cut

I'd like to propose two extensions for the Cut (;.) dyad.

-- Igor Zhuravlov 2009-12-26 16:55:18

extend Evoke Gerund

I'd like to propose the extension for the Evoke Gerund (`:) conjunction, described on page Extended forks. Following is example of such extension usage, e.g. for 3-fork ("9" is selected randomly for example only):

   NB. proposed evoke by extended Evoke Gerund (`:) functionality
   2 (+`%:`-`%`^`*`:9) 4
0.00379719j0.00219231

   NB. evoke using the model adverb from script supplied with page 'Extended forks'
   2 (+`%:`-`%`^`* fork3) 4
0.00379719j0.00219231

In gerund, Cap ([:) (at leftmost position in execution tree) and Self-Reference ($:) verbs support is desirable.

-- Igor Zhuravlov 2009-12-26 19:30:00

document fit more completely

I'd like to request that the dictionary page for fit (customize, !.) documents all cases when fit works, not only some.

In particular, applied to key (monadic /.), fit is taken by the interpreter as key with tolerance, as Niemiec points out on the forum eg.

   (1 + 1e_14 * 1 0 0 1 0) </. 'abcde'
+-----+
|abcde|
+-----+
   (1 + 1e_14 * 1 0 0 1 0) </.!.0 'abcde'
+--+---+
|ad|bce|
+--+---+

and it seems that this isn't documented in the dictionary anywhere.

Applied to expand (diadic #^:_1 and also monadic m&#^:_1), fit sets the fill element, eg.

   1 0 0 1 0 #^:_1!.'-' 'ab'
a--b-
   1 0 0 1 0&#^:_1!.'-' 'ab'
a--b-

which is documented clearly on the dictionary page for ^: but not on the page for !..

I would like to request that every left argument that the fit conjunction handles (which may include ones I don't know about) be listed on the dictionary page for fit.

-- BJonas 2010-02-21 23:24:37

extend fit conjunction

This would allow overtake on a boxed array to supply the fill (boxed) element suitable for further processing.

In dictionary format -

Fit(Customize)  u !. v 

The case of !. with a verb right argument is defined in terms of the noun right
argument case (u !. n) as follows:                    

x u !. v y  <-->  x u!.(x v y) y
  u !. v y  <-->    u!.(  v y) y

and

Fit(Customize)  u !. n
This conjunction modifies certain verbs in ways prescribed in their definitions. 

Case  n is not a gerund, ...(same as current definition )
Case  n is a gerund. (Compare with the gerund cases of the merge adverb } and power conjunction ^: )
x u!.(v0`v1`v2) y  <-->  (x v0 y) u!.(x v1 y)  (x v2 y) 
x u!.(   v1`v2) y  <-->      x    u!.([`v1`v2)    y 
  u!.(   v1`v2) y  <-->           u!.(v1 y)    (v2 y)

Because a gerund is a boxed noun there may be an issue with the second case. It may be the case that a gerund may be a valid fill (or other customisation) element so that fit evoking the gerund would not be possible.

However having a verb right argument for the fit conjunction seems possible. The verb could inspect both x and y to determine an appropriate fill element.

-- Ian Shannon 2010-07-28 09:36:30

Document interpreting locatives completely in Dictionary

The j602 Dictionary tells what names are locatives, but it does not give the complete rules for how a locative is broken into parts and interpretted.

For example, it's not obvious which of these names are valid and what they mean: a_b_c_ a__b__c a__b_c_ a___b. From experimenting with j701 on x86-linux, a_b_c_ means a_b in the locale c; a__b__c is a doubly indirect locale reference; but a__b_c_ is an error even though I think it would be useful if it was an indirect reference for the name a in the locale referred to by b_c_. In any case, I'd like to see definitive and concrete rules though, not only examples.

-- BJonas 2010-08-25 22:12:53

Allow proverbs that are temporarily invalid to be created from atomic form

From experimenting with j701 on x86 linux, it seems that if the value of a name is currently a noun (or adverb or conjunction), then you cannot create a proverb referring to that name even by evoking that proverb from its atomic representation. Eg., if the value of a is 99, then b=:(<'a')@.0 or b=:(<'/';<<'a')@.0 gives an error. The case is similar with a name that is an indirect locative that currently refers to a nonexistent or invalid locale, eg. you cannot evoke <'a__b' if b has no value or has a value that is not a valid boxed locale name. I'd like to ask you to change this behaviour and allow such an atomic form to be evoked to a verb.

A proverb referring to such a name can exist, if it was created earlier when it was valid, and can become valid and callable later. If the change I suggest is made to the interpreter, you could evoke such a potentially valid proverb any time by evoking it from its atomic representation, and it would behave just as if you had created it an earlier time, that is, it could become callable later, or raise an error if called (as a verb) before it becomes valid. It's natural that you still shan't be able to create such a proverb by the grammar while the name is invalid, for if the name points to a noun (or adverb or conjunction) when it's moved by the grammar, then it has to take its value instead of creating a proverb; and by analog if the name refers to an invalid locale then it does make sense to raise an error because there's no way to know whether it should be treated as a verb or a non-verb. (The same applies for creating a proverb with the ~ adverb instead of the grammar.)

There are multiple ways such a proverb can become valid: the current locale or its search path could change, bringing the intended name (or the referred name used as a locale) back into scope; the name (or the part) could cease to be shadowed by a local name, or be created as a local name; or simple the name can be reassigned a verb, or the second part assigned a locale value. In such a case, you might be able to call such a name again.

The reason why I don't like the current behavior is that it makes it possible to have a verb of which you take the atomic form and then evoke it from that form, you get an error. As far as I know, this is the only case when that can happen. It is useful to be able to store any verb (or noun or adverb or conjunction) in atomic form and then turn it back any time to get the same thing, and it does usually work. I'd like to think that a program can rely on that it always work. An example where this could be useful is when you have a program like jevalbot that saves the state of the interpreter by atomizing (with 5!:1) and serializing (with 3!:0) the value of every name and export it, and later reload that state to another interpreter instance. This could thus fail if some name referred to a verb that contained inside an indirect locative proverb, which uses as its locale reference another name that would only be filled out later (you can't except the program to know which order to reload these names).

-- BJonas 2010-08-25 22:49:31

Allow @ with noun right argument

currently verb @ noun gives domain error. I suggest it to have meaning verb @ (noun"_) same way as N V V fork was extended

-- AndrewNikitin 2010-08-29 04:38:02

System/Interpreter/Requests (last edited 2010-08-29 04:38:02 by AndrewNikitin)