> > It keeps tacit adverbial and conjunctional programming weak.
>
> Refusing to use available tools does accomplish that.
Did you mean explicit tools?
> I took a look at that problem, basically, it's this:
> ...
> Once I had that, I think this explicit model would be straightforward
> to convert to tacit form:
> ...
"That is easier said than done." I am afraid I could be waiting for your
actual tacit anonymous fixed version of the conjunction INTEGRATE
indefinitely.
> > Carefully ;) I have trained a few people over the years with hardly any
> > difficulty.
>
> That's not actually an answer.
It has worked for me.
> That implication is, I think, a sign of limited thinking, since you
> could also use tacit entities for the heavy tasks, dipping into
"That is easier said than done." I will keep waiting for your, just over
the lightweight class, tacit anonymous fixed version of INTEGRATE which you
might, or might not, be able to produce.
> > 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.
No, that was a question.
> That said, this is an interesting topic.
We agree!
PS. I am still curious, what part of the j903 language would you advise to
remove to avoid the following interpreter crash?
J=. ((<@:((":0) ,&:< ]) , ])([.].))(`:6)
CRASH=. 5!:1@<'J'
CRASH J ;)
_____________________________________________________________________________
On Tue, Dec 28, 2021 at 4:27 PM Raul Miller <[email protected]> wrote:
>
> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
