I haven't read the spoilers yet, so I'd like to ask a couple of clarifying
questions:
- re (Ca f p g) vs ([: f g) : must a difference be identified in the
/output/ of these two verbs when applied to identical arguments, or are
solutions allowed which show differences in products derived from these two
("identical") verbs? In the extreme, is it sufficient to show significant
(orders of magnitude) differences in performance?
- re the interpreter "preferring" @: to [: in certain cases: is puzzle
limited to the output of 13 : n , or may we demonstrate the preference in other
contexts?
Fun stuff! Thanks for posing the puzzles.
-Dan
On Dec 5, 2012, at 6:01 PM, Jose Mario Quintana <jose.mario.quint...@gmail.com>
wrote:
> Ian writes:
>
>> If u and v are verbs, do (u@:v) and ([: u v) really behave the same
>> under all circumstances?
>
> The lesser known fork form (Ca u p v) where (Ca=. [) (or (Ca=.
> AnyVerb)) and (p=. @]) (or (p=. @:])), which has been identified at
> least for a decade (
> http://www.jsoftware.com/pipermail/general/2002-September/008617.html
> ), can replace literally ([: u v) in instances where (u@:v) would
> require additional parenthesis. For example,
>
> ([: +: +/)3 4 5
> 24
> (Ca +:p +/)3 4 5
> 24
> ([ +:@] +/)3 4 5
> 24
>
> 2.5 (>. % [: <. + * -) 4
> _0.4
> 2.5 (>. % Ca <.p + * -) 4
> _0.4
> 2.5 (>. % [ <.@] + * -) 4
> _0.4
>
> The reason is that (Ca u p v) is also a fork and it bonds to its
> context in the same manner as ([: u v) does. Yet, there are
> exceptions to the equivalance! How come? Under what circumstances?
> Finding the answer to this questions can be seen by tacit fans as a
> puzzle to be solved and a solution is given at the end of this
> message.
>
> Ric writes:
>> If you restrict yourself to writing explicit J then it is perfectly
>> possible to get away without using capped fork.
>
> Although I agree with the statement above the complementary statement
> (if you restrict yourself to writing tacit J then it is perfectly
> possible to get away without using capped fork) also holds.
> Furthermore, some (myself included) routinely avoid it. Incidentally,
> my attitude is the reverse of Linda's attitude. I have an easier task
> because generally is fairly easy to replace ([:) using (@) (together
> with ([) and (])) than to replace (@) in terms of ([:) without
> introducing ("). A reason given for favoring ([:) over (@ :) is that
> (13 :) does so; however, there are instances where the interpreter
> even favors atop (@) over ([:) . Finding such an instance is another
> puzzle and one solution is also shown at the end of this message.
> (This is a tricky puzzle thought.)
>
> Don writes,
>
>> BASIC is the programming language that was popularized when personal
>> computing became common. It and the popular programming languages today are
>> all essentially scalar. They handle one element at a time and use loops to
>> handle arrays. APL, J and a few other languages running around today are
>> array oriented. Loops and so many techniques used to write good programs in
>> scalar languages are for the most part unnecessary in array languages like
>> J. But once one learns the scalar approach to programming these scalar
>> techniques are well entrenched.
>
> It is also possible even if you restrict yourself to writing tacit J,
> to code verbs using loops handling one element at a time; however,
> this is not only pointless but is also generally quite more difficult
> in this case. In other words, tacit programming naturally compels the
> array approach and, in my opinion, beginners should be encouraged to
> (try to) code simple verbs tacitly. I began translating simple verbs
> from explicit code to tacit code because these tasks were entertaining
> puzzles to solve and I used (13 :) to get hints when I was stuck. At
> some point I realized that any verb, simple or complex, could be coded
> tacitly and later I convinced myself that coding tacitly, and fixing
> the tacit code of, large systems made a lot of sense and others and I
> have been coding in this manner for many years; I now use (13 :) to
> translate alien explicit code to a familiar dialect.
>
> My answer to my own questions follows: How come? Under what
> circumstances? Because, and when, the interpreter is both very smart
> and yet not smart enough. For example,
>
> - &. (^. @: *:) 1 2 3
> 1 0.5 0.333333
> - &. ([: ^. *:) 1 2 3
> 1 0.5 0.333333
> - &. ([ ^.@] *:) 1 2 3
> |domain error
> | -&.([^.@]*:)1 2 3
>
> (^. @: *:) (d.1)
> +: * %@*:
> ([: ^. *:) (d.1) NB. This is an instance where the interpreter
> favors @ over [:
> +: * %@*:
> ([ ^.@] *:) (d.1)
> |domain error
> | ([^.@]*:)(d.1)
>
> Incidentally, I am also puzzled:
>
> Does anybody know why the interpreter resolves,
>
> (^. @: *:) (d.1)
> +: * %@*:
>
> but it does not resolve the following sentence of the same kind,
>
> (^. @: *:) (^:_1)
> ^.@:*:^:_1
>
> considering that it knows,
>
> (^. @: *:) b._1
> %:@:^
>
> ?
>
> ____________________________________________________________________________
>
>
> On Thu, Nov 29, 2012 at 11:49 AM, Ian Clark <earthspo...@gmail.com> wrote:
>> Department of Sudden Doubts...
>>
>> If u and v are verbs, do (u@:v) and ([: u v) really behave the same
>> under all circumstances?
>>
>> If so, where would I go to find this fact written up?
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
>
> On Sat, Dec 1, 2012 at 3:03 AM, Ric Sherlock <tikk...@gmail.com> wrote:
>> Hi Alex,
>> Not sure if you're aware of the trig script available as part of the
>> 'math/misc' addon, but it may contain at least some definitions you'd like
>> to use. If you have the addon installed then you can load the definitions
>> using:
>> require 'trig'
>>
>> If you restrict yourself to writing explicit J then it is perfectly
>> possible to get away without using capped fork.
>>
>> Ric
>>
>>
>> On Sat, Dec 1, 2012 at 5:14 PM, Alex Giannakopoulos <aeg...@blueyonder.co.uk
>>> wrote:
>>
>>> On 30 November 2012 16:17, Bo Jacoby <bojac...@yahoo.dk> wrote:
>>>
>>>> J is a rich language, and it might be a good idea to define an elementary
>>>> subset for beginners.
>>>
>>>
>>> Couldn't agree more.
>>> A simple startup configuration file. Define verbs for trig functions so
>>> they don't look stupidly arbitrary.
>>> Some other elementary functions too, like polar2rect and rect2polar
>>> conversions that act on vectors (none of this xfy binary stuff here
>>> please), you know, stuff like you can find on *calculators*.
>>> Define dot-product, matrix-multiplication, cross-product, determinant, etc,
>>> as user-friendly built-in verbs. When I am a beginner, I DO NOT, repeat
>>> NOT want to know about the . operator at the level of the jdict, it is a
>>> highly advanced subject, intriguing - yes, but not for newbies. Yet I do
>>> want to do matrix ops. I was told this was a language for linear algebra.
>>> It would probably be a good idea, then, if we could do some linalg -
>>> straight out of the box - without serious brain damage. I have had abuse
>>> hurled at me by math teachers who have seen J's linalg primitives (LOL).
>>> Add some nice libs for equation solving while we're at it. Simultaneous
>>> and also some numeric solvers. This is what people want. A language, not
>>> an assembler for a language.
>>>
>>>
>>>> J is a nice calculator for elementary computations. You can do a lot of
>>>> computing without knowing anything about binomial coefficients and taylor
>>>> expansions and capped forks.
>>>
>>>
>>> Agree with the first two, NO way on the third. Even the 13 verb gives you
>>> capped verbs, there is no way to begin learning J without it. Also they
>>> solve the problem of having to figure if you should use At or Atop,
>>> invaluable for a beginner who hasn;t quite mastered rank yet.
>>>
>>> This problem, which once again gives rise to a long thread, could easily be
>>> solved by a highly visible Programming FAQ page, with lots of links to.
>>> Deal with capped forks, @ and @: and why you can't have things like +/ a
>>> b c You know, the questions people *keep asking*. Remove ancient
>>> irrelevant stuff like the use of x. and y. We are not at J401 any more.
>>>
>>>
>>>> If you need to understand everything in order to be happy, then you may
>>> be
>>>> unhappy. I taught my son elementary APL when he was 10 years old, and he
>>>> loved it!
>>>>
>>>
>>> Would he have been just as happy at 14 when he had to use the cosine rule
>>> to solve a triangle? Would he really prefer
>>> cosrule_getang =: 13 : '_2&o.(((+/*:}.y)-*:{.y) % */ 2, }.y)'
>>> or
>>> cosrule_getang =: [: _2&o. (([: +/ [: *: }.) - [: *: {.) % [: */ 2 , }.
>>> to
>>> cosrule_getang := (Aa,B,C) -> acos((B^2+C^2-Aa^2)/(2.0*B*C));
>>> Just wondering...
>>>
>>> These are simple enough things to do, and I speak as a J newcomer. There's
>>> not many languages you can say that about after two and a half years! The
>>> Zen of J, grasshopper.
>>>
>>> Incidentally, is there a way to cap a monadic hook on the left?
>>> For example (=<.) was mentioned, but obviously it allows dyadic arguments,
>>> and fails if they are offered.
>>> Short of wrting monad : 'y=<.y' is there a way I can keep it monadic (and
>>> implicit)?
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
>
> On Sun, Dec 2, 2012 at 9:12 AM, Don Guinn <dongu...@gmail.com> wrote:
>> BASIC is the programming language that was popularized when personal
>> computing became common. It and the popular programming languages today are
>> all essentially scalar. They handle one element at a time and use loops to
>> handle arrays. APL, J and a few other languages running around today are
>> array oriented. Loops and so many techniques used to write good programs in
>> scalar languages are for the most part unnecessary in array languages like
>> J. But once one learns the scalar approach to programming these scalar
>> techniques are well entrenched.
>>
>> Take a person who has never programmed and there is nothing to unlearn.
>> They don't keep looking for all those neat techniques they spent years
>> mastering but are not needed in J. It is difficult to convince a programmer
>> to ignore what he knows and loves. This makes it hard to teach J to
>> programmers.
>>
>> BASIC in this discussion represents all languages which are scalar in their
>> approach to programming. What we think of as the "original" BASIC is the
>> version developed by Apple and other micro computer vendors to fit on a 4K
>> micro computer. Not the real original BASIC developed at Cambridge to run
>> on a mainframe.
>>
>> Many of the popular programming languages are adding array handling, but
>> the array handling is an add-on. It doesn't fit well. The scalar approach
>> is still their primary approach to programming.
>>
>> The library extensions to VB, C, Java etc. are well documented and
>> considered part of the language. One really can't write a decent
>> application in them without extensive use of those library extensions.
>>
>> J is well documented in the J dictionary and vocabulary. One can write
>> decent applications in J without using much from the J library extensions.
>> It is being kind to say that the library extensions for J are poorly
>> documented. But today's applications need graphics, GUI, access to data
>> bases and used on devices only accessible through library extensions.
>> Telling someone to look at the script in the library to find out how to use
>> it won't work.
>>
>> J7 is addressing this change in programming. But the library extensions
>> necessary for J to build an application for what people expect requires
>> extensive use of these library extensions.
>>
>> We need to thoroughly document these extensions and consider them part of
>> the J language.
>>
>> On Sat, Dec 1, 2012 at 10:43 PM, Alex Giannakopoulos <
>> aeg...@blueyonder.co.uk> wrote:
>>
>>> I am not sure Ian really meant BASIC when he said "people who know BASIC".
>>> Perhaps the gist of what he meant was "people who want to do basic
>>> programming".
>>>
>>> No-one really uses old-style BASIC today, regardless of what marketing
>>> blurbs may say. I have *never* seen anyone recommend it to people who ask
>>> "what language should I start with?" on any programming forum whatsoever.
>>>
>>> .. . .
>> ----------------------------------------------------------------------
>> 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
