the long line you quote is just an assignment statement. It produces such
names as:
sign
* :(*@])
The : seperates the monad and dyad versions of the verb.
A benefit of tacit code is that it has minimal overhead. Your only 2 options
for calling sign in a dyadic context are *@] or *@[. The name saves you from
using the first form. If you want you can do sign@[ if you wanted to use the
2nd form.
The perfomance hits are very minor. This result shows its even faster somehow.
30 timespacex '+/@]@] i.1000'
4.37333e_6 11264
30 timespacex '+/ i.1000'
7.41333e_6 10368
30 timespacex 'iota 100000'
0.000510667 1.0505e6
30 timespacex 'i. 100000'
0.000640096 1.04986e6
but there is a lot of variation between runs.
I do propose this adds simplicity. The purpose of the fancy assignment process
is that you can move symbols into other categories, just changing data and not
code.
----- Original Message -----
From: Don Kelly <d...@shaw.ca>
To: programm...@jsoftware.com
Sent: Wednesday, November 25, 2015 1:46 AM
Subject: Re: [Jprogramming] dyadic J
I came from APL and found that then "one liners" while clever, do not
allow for easy interpretation . This is, while a neat one-liner is not
easy to interpret. even though you have given interpretation of steps.
I look at
*`<`>`<.`>.`<:`>:`#`=`+:`-:`|`|.`+`-.`*:`{`}:`{:`{.`}.`;`,`,.`,:`;:`C.`A.`q:`e.`/:`\:
4 : '(> y) =: (x `:6) : (x `:6@]) label_. y '"0 ;: 'sign box open floor
ceiling decr incr tally self double halve magnitude reverse conjugate
not square catalog curtail tail head behead raze ravel items itemize
words cycle anagramindex factors razein gradeup gradedown'
and wonder "what the hell !"
Is this a benefit?
Is there a need for a dyadic interpretation (and most, operators,
as far as I can see, do this) for all operators?.
some operations do not need this and doing this may be convenient but do
add overhead that may not be of actual use may be counterproductive
-definitely in terms of coding, at a more basic level than J. that may
result in bloated or slower internal algorithms
I suggest, as one who does not have your experience with J, that "KISS"
is a principle to follow.
Does your suggestion follow this?
With respect.
Don (old fart) Kelly
On 11/24/2015 7:03 PM, 'Pascal Jasmin' via Programming wrote:
> Here's my suggested implementation. The only linebreaks are at empty lines.
>
>
> *`<`>`<.`>.`<:`>:`#`=`+:`-:`|`|.`+`-.`*:`{`}:`{:`{.`}.`;`,`,.`,:`;:`C.`A.`q:`e.`/:`\:
> 4 : '(> y) =: (x `:6) : (x `:6@]) label_. y '"0 ;: 'sign box open floor
> ceiling decr incr tally self double halve magnitude reverse conjugate not
> square catalog curtail tail head behead raze ravel items itemize words cycle
> anagramindex factors razein gradeup gradedown'
>
> i.`i: 4 : '(> y) =: (x `:6) : (+ x `:6) label_. y '"0 ;: 'iota steps'
>
>
> ?`?. 4 : '(> y) =: (x `:6) : (x `:6@#) label_. y '"0 ;: 'roll rollf'
>
>
> +.`*. 4 : '(> y) =: (x `:6) : (({ x `:6)"0) label_. y '"0 ;: 'real length'
>
>
> indices =: I. : ( I.@:=)
>
> The only special monad not previously mentioned
>
> 3 indices 3 5 1 3 2 3
> 0 3 5
>
>
> all names are lowercase, and match the dictionary except
>
> sign incr decr iota rollf items factors
>
>
> ----- Original Message -----
> From: 'Pascal Jasmin' via Programming <programm...@jsoftware.com>
> To: "programm...@jsoftware.com" <programm...@jsoftware.com>
> Sent: Tuesday, November 24, 2015 4:39 PM
> Subject: Re: [Jprogramming] dyadic J
>
> The audience would be people like me when I started. I came from VB and
> dabbling in lisp python ruby. Not APL.
>
> The best tip for reading tacit code that is not published very prominently is
> that a fork is
>
>
> A D A - (A)mbivalent (D)yad
>
> which still leaves the interpretation step of is A actually M or D? Its
> extremely rare for a train to be meaningful under both M and D.
>
>
> The first objective is readability. Seeing a verbose built in name would
> clue you in that this is primarily a monadic verb.
>
> In terms of less error prone, when you write i. (or #) you mean either iota
> or indexof. Not some flexible ambivalent version of i. So if you used iota
> as one of the edges of your fork, you can still make the whole fork dyadic
> while one tine is monadic. You can also use iota@[ to refer to x side.
>
> While you can remember for any sentence that you intended i. to be iota for
> the next 5 to 30 minutes, that memory fades. A month later you are in the
> same position as if I were to try to guess what you intended. With a coding
> style of word for monad, symbol for dyad, it seems to me to be an obvious
> significant boost in clarity.
>
>
> What originally gave me the idea is that if every verb in J had a dyad
> implementation, then J can be implemented in every other language. For
> example in python
>
> add(y, x=0) is a function signature where x is an optional parameter.
> Removing monad as a verb category makes it possible to handle missing
> parameters at the function level in some languages, and with an adverb
> equivalent to @] in others.
>
> Implementation in other languages is as far as I can tell good for J in that
> J is likely to retain a performance advantage, and it can only risk infecting
> others into J-ing. Both the implementation in other languages and newcommers
> ability to understand is easier if there are fewer categories of functions to
> understand and implement.
>
> see also
>
> https://www.reddit.com/r/dailyprogrammer_ideas/comments/3tz8ds/3_part_series_turn_your_favorite_language_into_an/see
>
>
>
>
> When everything is a dyad with default : ($:@]) implementation (if not a
> "real" dyad) then it also makes conjunctions easier to write/use.
>
>
> a cute implementation of the proposal:
>
> Monad =: : ($:@])
> count =: # Monad
>
> Consider:
>
> hook_z_ =: 2 : '([: u v) : (u v) '
>
> The core issue in this conjunction is that u can be monadic or dyadic, but
> for some reason v must be monadic. There are plenty of more sophisticated
> conjunctions that have to deal with this issue and make these tradeoffs, but
> the actual best solution for a conjunction here would be to return:
>
> ([ u v)
>
> if the user of the conjunction wants to use monadic v then he passes (v@]).
> if he wants monadic u then passes u@]. And it call all be part of a larger
> dyadic train. This is already possible of course, but the design temptation
> when writting the conjunction is to guess whether u and v will be monadic
> most of the time and so create restrictions around optimizing the most
> frequent use case.
>
> With this convention, you can now always use monads when dyads are expected,
> and so can freely design modifiers as though dyads are the only relevant
> consideration.
>
> While I have what I think are useful enhancements for built-in monads, one
> good case for making them all
> : ($:@])
>
> is that a useful alternative hook conjunction above is that
>
> ([ u v) has useful intuitive interpretations for M M, M D , D M , and D D.
>
> Similar to the Monad definition above,
>
> Dyad =: 2 : 'm&$: : v'
>
> For all dyads, there exists a default x that is at least not inconvenient.
> In the worst case that x is ERROR/null/i.0 0.5 _
>
>
>
>
>
>
> ----- Original Message -----
> From: Dan Bron <j...@bron.us>
> To: J Programming <programm...@jsoftware.com>
> Sent: Tuesday, November 24, 2015 3:13 PM
> Subject: Re: [Jprogramming] dyadic J
>
> It would be interesting and helpful to see some motivating examples — code
> that is shorter, clearer, less error-prone, whatever, using “dyadic J” than
> the original “standard J”.
>
> Would also be helpful to describe the intended audience. For example, are the
> motivating examples shorter, clearer, less error-prone, whatever, for
> novices? Calculus students? Immigrants from APL? J veterans?
>
> -Dan
>
>> On Nov 24, 2015, at 3:02 PM, 'Pascal Jasmin' via Programming
>> <programm...@jsoftware.com> wrote:
>>
>> A simple project whose benefits are described shortly:
>>
>> replace (add shaddow names) most of the monadic built-in verbs with
>> ambivalent definitions that may add extra utility.
>>
>> count =: # : #@]
>>
>> all monads have an obviously intuitive dyad alternative of v@], but some
>> monads can be given additional utility in a way that is still providing the
>> fundamental function. For instance
>>
>> iota =: i. : (+ i.)
>>
>>
>> 1 iota 3
>> 1 2 3
>>
>> roll =: ? : ?@#
>>
>> 5 roll 6
>> 1 1 5 4 2
>>
>>
>> benefits:
>>
>> providing extra utility to verbs is nice, but not the main reason.
>>
>> It would make J more approachable if every verb is a dyad whose monadic
>> interpretation can be understood as an ommitted default parameter.
>>
>> Its easier to read tacit code, for instance if iota and i. look different,
>> and the verbose version is verbose for the specific reason that it is a
>> monad. Tacit forks would look more like (word symbol word) if they are
>> intended as monadic forks, but may have dyadic tweaks. examples:
>>
>>
>> (3 * iota) 3
>> 0 3 6
>> 1 (3 * iota) 3
>> 3 6 9
>>
>>
>> The above tweak is a practical dyadic variation of essentially the same
>> fork, whereas with i. in the fork, the dyad use is likely a misapprehension
>> of the function.
>>
>> this may be cool too,
>>
>>
>> 1 (iota"0 iota) 4
>> 0 0 0
>> 1 0 0
>> 1 2 0
>> 1 2 3
>>
>> The main benefit stated more succinctly is that real dyads would look
>> different than real monads, but overall fewer errors would occur as a result
>> of valence errors, and it also shortens some code.
>>
>> details:
>>
>> % - ^ ^. #. #: ] [ 0: ": j. p: r. p.. are examples of monads that would not
>> get a shaddow name, because their dyad is already a "default x"
>> implementation.
>>
>> * %. [: ". I. { ;: may have useful dyad tweaks I can't think of
>>
>>
>> Some verbs would have weird names
>>
>> real_imag =: +. : ({ +.)
>> length_ang =: *. : ({ *.)
>>
>> these may be bad ideas, but are interesting:
>>
>> double =: +: : (+:@]^:[) NB. double x times. -:*:
>>
>> curtail =: }: : (-@[ }. ]) NB. but }:@] would be more useful
>>
>> do =: ". : (".@(, ' ' , ]))
>>
>> Another approach is to avoid providing any improvements to the dyadic
>> version of monadic functions and instead make them all have dyad version of
>> v@]
>>
>> Assuming that improvements are useful, can you think of any alternate
>> implementations for ambivalent:
>>
>> * %. [: ". I. { ;:
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
