On Tue, Dec 28, 2021 at 1:42 PM Jose Mario Quintana
<[email protected]> wrote:
> It keeps tacit adverbial and conjunctional programming weak.

Refusing to use available tools does accomplish that.

> "However, once one is outside the comfort zone things get tricky.  Doubters
> can try to write a tacit version of the conjunction INTEGRATE appearing in
> the following post (ignore the fact that the calculus add-on is written
> explicitly)
>
> [Jprogramming] Evaluating a Gerund Array
> http://www.jsoftware.com/pipermail/programming/2015-April/041621.html

I took a look at that problem, basically, it's this:

require'math/calculus'

deriv=: deriv_jcalculus_ _1
integ=: deriv_jcalculus_  1

INTEGRATE =: {{
  if. ('"') = >0{,>(v`'') do.
    u deriv * v
  else.
    (u deriv * v) -  (u deriv INTEGRATE (v integ))
  end.
}}
NB. It looks like the 'if.' test here is a crude heuristic aimed at
determining if v is a constant function.

with examples

   ^ INTEGRATE *:
and
   (2&o.) INTEGRATE (^&3)

The second example fails for me, sadly, because deriv_jcalculus_
currently can't figure out that the derivative of -@:(2&o.) is
-@:(1&o.)  So that's something that one of us should look at.

Also, the math/calculus implementation really should provide an
isConstant adverb (or verb operating on a gerund) so that this kind of
thing could be reliably incorporated into its implementation.

Anyways for a tacit workalike here, I would throw some explicit
adverbs into my toolkit, and I would want a variant of
deriv_jcalculus_ which operated on gerunds.

The explicit adverbs would promote a verb to a conjunction which
passed its arguments as gerunds to the base verb. Perhaps something
like this:

abstract1=: {{
  u{.v`''
}}

abstract2=: {{
  m=.5!:5<'u'
  2 :('0!:0 m=.',m,{{)n

    (u`'') m v`''
}})
}}

And, to emulate a math/calculus implementation which operated on
gerunds, I might use

require'math/calculus'
deriv=: (`:6) (deriv_jcalculus_ _1) (`'')
integ=: (`:6) (deriv_jcalculus_  1) (`'')

Once I had that, I think this explicit model would be straightforward
to convert to tacit form:

forking=: {{
   (x`:6 u y`:6)`''
}}

integrate=: {{
  if. '"' =(0;0){::y do.
    x deriv *forking y
  else.
    (x deriv *forking y) -forking x deriv integrate y integ
  end.
}}

> Sure, you are a member of the vast majority of users that follow the
> developers' strong advice and write tacit entities just for performing
> lightweight tasks.  I am surprised that you kept reading my post that far;
> but, by all means, if that works for whatever you are doing with J just
> keep doing it.

That implication is, I think, a sign of limited thinking, since you
could also use tacit entities for the heavy tasks, dipping into
explicit code only for relatively lightweight issues related to
parsing.

> > I suppose by crashing the J session, but this is just one example.
>
> Some Jx programs are routinely, automatically, and furiously cranking up
> verbs and crunching numbers and text sometimes for more than a couple of
> weeks straight, apparently unaware that they should be crashing instead.
> Besides, often I interpret some crashes as a sign of a system's power, but
> that is me.  So, what part of the j903 language would you advise removing to
> avoid the following crash of the interpreter?

The crashing I was thinking of would happen at development time, when
the developer ventured into territory not supported by the
implementation.

> > More importantly, how do you teach people to understand that kind of
> > construct?)
>
> Carefully ;) I have trained a few people over the years with hardly any
> difficulty.

That's not actually an answer.

> > Finally, what's wrong with
> >
> >    ^@:-@:(*~) 2
> > 0.0183156
>
> Do I really have to indicate that that was just a very simple illustration
> taken from the BQN's documentation?

That's not an answer, either.

That said, this is an interesting topic.

And, I think the INTEGRATE example relates to the earlier discussions
about tacit fork construction. However, since it also requires
recursion, I think that an adverb/conjunction train which, when
applied, forms into a verb train would not actually address this use
case. I do see how verbs which return verb results would be
specifically useful here, but from my point of view this could equally
be thought of as illustrating limitations of our current gerund
toolkit.

Thanks,

-- 
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to