J Challenge, and why I didn't like it... 
Author Message
 J Challenge, and why I didn't like it...



Quote:
>[...]
>The solution exists, but it lacks a certain APL/J tenet, that was
>first embodied in the reduction adverb, used in +/: don't embed
>variable functionality if you don't have to!  This is even more in-
>excusable in J since the construction of compound verbs is so much
>more extensive.

>Here it would have made much more sense to create a single verb, let's
>call it C4, so that the definitions would have been:

>  klb =: 'klb'&C4
>  rlb =: 'rlb'&C4
>  NB.  I'm sure you get the rest, but why go beyond C4?

 Actually, I was tempted to make it an adverb, so one could create
a verb with:
   klb=. 'klb' MKVERB

 I went with a verb which creates the target verbs as a side-effect
for two reasons:
  - efficiency:  In a real application I would expect one to want to
    generate the necessary utility verbs once, rather than having to
    re-evaluate the argument and build the verb for each use of it.
  - while using assignment to directly create the verb is more elegant,
    it doesn't help in making all the utility verbs (at least without
    explicitly using execute).  And note that this was the actual
    challenge -- to create *all* the verbs.

Quote:

>The challenge therefore suffered from the sum/prod tendency that
>other languages require because of the lame way they allow verbs
>as arguments.  

>Even the "extra marks" section pushed the absurdity:

>> Extra marks: On the off chance that you don't actually need all of
>> the 108 verbs defined by this script, it's simple to redefine it
>> to define only those verbs which are named in an argument.

>since of course the existence of C4 would allow whatever functionality
>was needed.

 And with your C4 verb, you'd also be able to do things like:
   ('rlb';'rtb') C4&.> '  remove leading';'remove trailing    '

 I'm interested in what the inside of your C4 looks like.  Does it
create the particular verb based off the argument and then apply it,
or does it directly compute the result after looking at the left
argument?

--



Thu, 17 Sep 1998 03:00:00 GMT  
 J Challenge, and why I didn't like it...

Quote:
> Actually, I was tempted to make it an adverb, so one could create
> a verb with:
>   klb=. 'klb' MKVERB

Now THAT would be the proper challenge.

Quote:
> I went with a verb which creates the target verbs as a side-effect
> for two reasons:
>  - efficiency:

I'm smelling a false economy coming up...

Quote:
> In a real application I would expect one to want to generate the necessary
> utility verbs once,

Given that "necessary" would not be well defined without a deep script
analysis, i.e., another level of reconstruction after every change, a real
application would just define all verbs "just in case."

Quote:
> rather than having to re-evaluate the argument and build the verb for
> each use of it.
> - while using assignment to directly create the verb is more elegant,
> it doesn't help in making all the utility verbs (at least without
>  explicitly using execute).  
> And note that this was the actual challenge -- to create *all* the verbs.

The actual challenge was what I was questioning.  Why challenge to do
what amounts to defining "sum" and "prod" where +/ and */ are better APL/J?

Also the solution was simply an {*filter*} execute, which used local functions
and then f.'ed them.  If that was going to be the challenge, why not just
make strings out of the tacit forms of each verb:

instead of

and then build your execute that way?

Quote:
> >since of course the existence of C4 would allow whatever functionality
> >was needed.
>  And with your C4 verb, you'd also be able to do things like:
>    ('rlb';'rtb') C4&.> '  remove leading';'remove trailing    '

...which makes C4 that much MORE useful compared to the 180.

Quote:
> I'm interested in what the inside of your C4 looks like.  Does it
> create the particular verb based off the argument and then apply it,
> or does it directly compute the result after looking at the left
> argument?

Your belief in the existence of "my C4" is unjustified, and misplaced.
I was discussing the appropriateness of the challenge.

Now as for C5: the default left argument challenge, I'm kicking myself
that I didn't resist temptation and peek at the solution, since that
adverb is quite useful...

--
|\/| Randy A MacDonald       |"You just ASK them?"

     BSc(Math) UNBF '83      | APL: If you can say it, it's done.

                             | Also http://www.*-*-*.com/
------------------------------------------------<-NTP>----{ gnat }-



Fri, 18 Sep 1998 03:00:00 GMT  
 J Challenge, and why I didn't like it...


Quote:

>[...]
>> I went with a verb which creates the target verbs as a side-effect
>> for two reasons:
>>  - efficiency:

>I'm smelling a false economy coming up...

>> In a real application I would expect one to want to generate the necessary
>> utility verbs once,

>Given that "necessary" would not be well defined without a deep script
>analysis, i.e., another level of reconstruction after every change, a real
>application would just define all verbs "just in case."

 Script analysis seems needlessly complicated.  When I use a verb in a
script I make sure there is a definition for it.  Whether it is defined
by  makeverbs 'klb' ,  klb=. 'klb' MKVERB , or  klb=. 'klb'&C4  doesn't
really make much difference.

 Anyway, the efficiency to which I was referring is in regards to the
execution speed.  rlb, which by my solution would be defined as

'rlb'&C4.  The work in producing the specific verb is performed once
when generating the verb, rather than at every invocation.

Quote:
>>[...]
>> And note that this was the actual challenge -- to create *all* the verbs.

>The actual challenge was what I was questioning.  Why challenge to do
>what amounts to defining "sum" and "prod" where +/ and */ are better APL/J?

>Also the solution was simply an {*filter*} execute, which used local functions
>and then f.'ed them.  If that was going to be the challenge, why not just
>make strings out of the tacit forms of each verb:

>instead of

>and then build your execute that way?

 That would also have worked as a solution.  I prefer manipulating verbs
rather than character string which represent them -- and that was the
actual point of the challenge: to put the user in a position where they
must combine the component verbs.  (Or at least showing such a combination
of verbs in the solution).  That's why the challenge insisted on the user
creating *all* verbs.

Quote:

>> >since of course the existence of C4 would allow whatever functionality
>> >was needed.

>>  And with your C4 verb, you'd also be able to do things like:
>>    ('rlb';'rtb') C4&.> '  remove leading';'remove trailing    '

>...which makes C4 that much MORE useful compared to the 180.

 Yep.  I still wouldn't use it though.  If I needed to solve the
above I'd probably just:

Quote:

>> I'm interested in what the inside of your C4 looks like.  Does it
>> create the particular verb based off the argument and then apply it,
>> or does it directly compute the result after looking at the left
>> argument?

>Your belief in the existence of "my C4" is unjustified, and misplaced.
>I was discussing the appropriateness of the challenge.

 Nahh..  I knew you hadn't written it.  If you did, though, my guess
is that you'd wind up doing much the same as the solution to this
challenge did wrt combining verbs.  If you'd do something different,
I'd be interested in seeing your solution. (And *that* would be much
more worthwhile than our current discussion, in my opinion.  :)

Quote:
>Now as for C5: the default left argument challenge, I'm kicking myself
>that I didn't resist temptation and peek at the solution, since that
>adverb is quite useful...

 I like that one a lot -- unfortunately I don't like my explanation of
the solution.  I made two attempts to fully describe how and why the
solution works, and lost myself in the words both times.  Sigh...

--



Sat, 19 Sep 1998 03:00:00 GMT  
 J Challenge, and why I didn't like it...

Quote:

>  Actually, I was tempted to make it an adverb, so one could create
> a verb with:
>    klb=. 'klb' MKVERB

>  I went with a verb which creates the target verbs as a side-effect
> for two reasons:
>   - efficiency:  In a real application I would expect one to want to
>     generate the necessary utility verbs once, rather than having to
>     re-evaluate the argument and build the verb for each use of it.
>   - while using assignment to directly create the verb is more elegant,
>     it doesn't help in making all the utility verbs (at least without
>     explicitly using execute).  And note that this was the actual
>     challenge -- to create *all* the verbs.

I think the way it was done was super and I do not know how many times
these kind of verbs have been needed in various applications I have
been working with.

Having a utility to create them all on the fly while development is
going on to be able to pick the one you need from a lot created and put
into the application is all I need.

Not to mention the value of learning J watching these kind of
operations.

I do not think it pays off to be too smart.

Be just smart enough to solve the application at hand. Trying to do
something I really am not sure of usually gets me into trouble.

I like to learn gradually. As time goes by I get into the habit of
using more and more J techniques. But I only use them in real life
applications when I am comfortable with them.

I always watch new applications with extra care when I have ventured
into a bold adventure of using something new (to me new that is) J
complicated way of doing things when there are unknown data going to
be handled in the application. Unknown in size and contents. Size is
usually a challenge. Something what works fine on a small amount may
reach over a limit and sometimes the whole approach of the application
needs to be reengineered.

I remember how proud I was when I first used gerund. I was scared for
many weeks that something would break for one reason or another.

I have not had a single instance of problem with it and now use it in
many instances.

I have yet to introduce a lot of things from J in real life
applications. Not that I do not think that they do not work. It has more
to do with me not understanding fully what is happening in those
operations. How they react to (to me ) unknown/untested data.

Contrary to popular believe then I am very cautious and careful :-)

--

http://www2.simi.is/~gosi
http://www.jsoftware.com



Sat, 19 Sep 1998 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Why didn't variable change?

2. Why didn't PL/I take off?

3. Why I didn't chose LISP

4. If dynamic typing didn't exist you'd have to invent it :-)

5. JS-EAI with *JS*-callback

6. Can't set IDT from C (hope I didn't send this before)

7. js.exception 3279.js

8. (meta) 'Sorry if my cancellations didn't work

9. The Smalltalk Store: Why we've been slow, and why we're getting better

10. Something else for a change / Parallel Computer for APL - in case you didn't know

11. I didn't know the Beetle relied on Smalltalk

12. Here are 3 ways to get window on top that didn't work for me

 

 
Powered by phpBB® Forum Software