Ah, I see what you are getting at (though now I am wondering why it
worked so flawlessly when I was testing it - today it has not worked
for me even once).
But, yes: the next verb is not a function. Instead, its user must
adopt a humpty dumpty mindset where doing the same thing with the same
argument will sometimes but not always produces a different result.
Still, we could do something like:
crazy=:1 :0
if.0=L.y do. 0;u y else.
(-.0{::y); u 1{::y
end.
:
if.0=L.y do. 0;x u y else.
(-.0{::y); x u 1{::y
end.
)
sane=: 1 :0
if.0<L.y do.u 1{::y else. u y end.
:
if.0<L.y do.x u 1{::y else. x u y end.
)
FC=: ]sane
FB=: next crazy
FT=: NotMatch sane
recur=: FC@(FB^:FT^:_)
Which, I now believe, is what you were getting at.
Thanks,
--
Raul
On Wed, Jan 17, 2018 at 7:04 PM, Jose Mario Quintana
<[email protected]> wrote:
> Alright, (by playing mental block defense again) you want to extend the prank
> a little longer. Why not? Nobody has complained yet; although someone had
> an urgent need to unsubscribe to this forum recently. :)
>
> There you go again...
>
>> The tail recursive routine in the evolve you referenced was recur, and
>> the FB^:FT^:_ form of recur would be:
>
>> recur=: next^:NotMatch^:_
>
>> I hope this helps,
>
>
> The fuzzy claim [2] has one example. This is wonderful! The form of,
>
> recur=: next^:NotMatch^:_
>
> is beautyfully simple versus,
>
> recur=. ]`([ $: next)@.NotMatch
>
> I cannot wait to see it in action...
>
> NB. Fresh session
>
> JVERSION
> Engine: j806/j64nonavx/windows
> Release: commercial/2017-11-06T10:01:33
> Library: 8.06.09
> Qt IDE: 1.6.2/5.6.3
> Platform: Win 64
> Installer: J806 install
> InstallPath: j:/program files/j
> Contact: www.jsoftware.com
>
> CHARS =: ' ABCDEFGHIJKLMNOPQRSTUVWXYZ'
> mutation =: CHARS&(] ,: [ {~ $@] ?@$#@[)
> fivePct =: 0.05 >: $ ?@$ 0:
> randomize =: (fivePct f.)`(mutation f.)}
> score =: +/@:~:"1
> copy100 =: 100 $ ,:
> NotMatch =: 1 - -:
> initial =: CHARS ([ {~ ?@$&#~ ) [
>
> next =: ((i. <./)@:score { ]) randomize@:copy100@:]
>
> recur=. ]`([ $: next)@.NotMatch
>
> evolve=. recur initial
>
> evolve 'METHINKS IT IS LIKE A WEASEL'
> METHINKS IT IS LIKE A WEASEL
>
> Yeah, that version converged to the target. So what?
>
> recur=: next^:NotMatch^:_
>
> evolve 'METHINKS IT IS LIKE A WEASEL'
> METHITWH UA IS LZIE AIWKASEL
>
> Darn!
>
> However,
>
> recur=. ]`([ $: next)@.NotMatch
>
> often does not even give a wrong answer for some targets,
>
> evolve 'HOWEVER SOMETIMES IT MAY NOT WORK PROPERLY FOR SENTENCES OF
> CERTAIN LENGTH'
>
> |stack error: randomize
>
> | evolve'HOWEVER SOMETIMES IT MAY NOT WORK PROPERLY FOR SENTENCES OF
> CERTAIN LENGTH'
>
> What about that fork of J that Erling mentioned which supposedly has Tail
> Call Optimization? Can that interpreter, so-called Jx really deal with
> this target?
>
> tco=. O.1 NB. (Jx adv)
>
> CHARS =: ' ABCDEFGHIJKLMNOPQRSTUVWXYZ'
> mutation =: CHARS&(] ,: [ {~ $@] ?@$#@[)
> fivePct =: 0.05 >: $ ?@$ 0:
> randomize =: (fivePct f.)`(mutation f.)}
> score =: +/@:~:"1
> copy100 =: 100 $ ,:
> NotMatch =: 1 - -:
> initial =: CHARS ([ {~ ?@$&#~ ) [
>
> next =: ((i. <./)@:score { ]) randomize@:copy100@:]
>
> recur=. ]`([ $: next)@.NotMatch tco
>
> evolve=. recur initial
>
> evolve 'HOWEVER SOMETIMES IT MAY NOT WORK PROPERLY FOR SENTENCES OF
> CERTAIN LENGTH'
> HOWEVER SOMETIMES IT MAY NOT WORK PROPERLY FOR SENTENCES OF CERTAIN LENGTH
>
> Damn! It converged to the target.
>
> Nevermind, next^:NotMatch^:_ still is so beautiful and simple.
>
> ;)
>
> PS.
>
>> If F is something else,
>> I guess I would have to do something else, also.
>
> Thank you for this superb explanation; it was so helpful, clear and
> unambiguous.
>
> ;)
>
>
> On Wed, Jan 17, 2018 at 11:43 AM, Raul Miller <[email protected]> wrote:
>
>> If you are expecting me to be perfect, I expect you are sadly mistaken.
>>
>> In related news, I don't see what you are trying to get at, here.
>>
>> Thanks,
>>
>> --
>> Raul
>>
>>
>> On Wed, Jan 17, 2018 at 11:03 AM, Jose Mario Quintana
>> <[email protected]> wrote:
>> > Pranks are usually performed (in the US) on April 1st :) The mental
>> block
>> > defense was a nice touch but it gave it away... Unable to recall what
>> the
>> > verb evolve does? A master of the J universe could not figure out what
>> the
>> > verb onemore does? Yeah, right!
>> >
>> > The lack of a single example of FB and FT, and the extensive obfuscating
>> > taking including instances of I guess this, I guess that and I guess the
>> > other was also a clue.
>> >
>> > As I said earlier in the thread: it has been somewhat entertaining. I
>> had
>> > a suspicion from the beginning because your "claim" in [2], not that [1]
>> > makes more sense, reminded me of,
>> >
>> > Not even wrong
>> > http://en.wikipedia.org/wiki/Not_even_wrong
>> >
>> >
>> >> [1]
>> >>
>> >> If I have a tail recursive function F, which calls function G, there
>> >> is normally no problem with G signaling that F needs to exit. Just
>> >> return a distinguished value from G and in F have an if statement
>> >> which returns when that happens. Since F is tail recursive, nothing
>> >> more needs done.
>> >>
>> >> So I would like to see an example of how this description:
>> >>
>> >> >> I have a deeply embedded function that discovers that it has
>> > completed the
>> >> >> task set before it. ...
>> >> >>
>> >> >> This function was not part of the initial design.
>> >>
>> >> has anything to do with tail recursion.
>> >>
>> >> [2]
>> >>
>> >> If I have a recursive verb (F y) implemented in J, which satisfies the
>> >> constraints for tail recursion, I believe that there is always a pair
>> >> of companion functions (FB y) (FT y) such that an F workalike can be
>> >> written:
>> >>
>> >> F=: FB^:FT^:_ y
>> >>
>> >> which satisfies the "bounded stack usage" guarantee of tail recursion.
>> >> And this form has an additional advantage, which is that a rewrite
>> >> which removes the bounded stack character requires work on the part of
>> >> the developer which is quite significant - it's unlikely that you will
>> >> have someone making such changes without realizing that they are doing
>> >> so.
>> >>
>> >> But I would be interested in seeing a counter-example that destroys my
>> >> belief, if counter examples exist.
>> >
>> >
>> > PS. I am surprised you did not continue with your latest prank; it even
>> > has a "quotation." :D
>> >
>> >
>> >> The statement there, "Only one of these explanations is valid" is both
>> >> unsupported and arguably false:
>> >>
>> >> 0 = 0 * 0
>> >> 0 = 0 * 1
>> >>
>> >> This leads into some fairly deep issues in mathematics. It also has to
>> >> do with the distinction between relations and functions with function
>> >> domains with inverse functions, and with concepts of equality.
>> >>
>> >> Still, in functional contexts, this is also a real problem and it's
>> >> entirely reasonable for a programming language or mathematical text to
>> >> standardize on a single result.
>> >
>> >
>> >
>> >
>> > On Tue, Jan 16, 2018 at 3:18 AM, Raul Miller <[email protected]>
>> wrote:
>> >
>> >> On Tue, Jan 16, 2018 at 12:08 AM, Jose Mario Quintana
>> >> <[email protected]> wrote:
>> >> > First, you wrote,
>> >> >> But I would be interested in seeing a counter-example that destroys
>> my
>> >> >> belief, if counterexamples exist.
>> >> >
>> >> > In your last message you wrote,
>> >> >
>> >> >> The use of FC is indeed necessary if the function being translated
>> >> >> needs to be evaluated multiple times with the same arguments (in a
>> >> >> single call).
>> >> >
>> >> > It seems that something has been accomplished: your belief has been
>> >> > destroyed. But something might still be missing... I am playing the
>> >> > devil's advocate now (no offense), you have not shown an actual
>> >> > counterexample (F) refuting you fuzzy claim when "then function being
>> >> > translated needs to be evaluated multiple times with the same
>> arguments
>> >> (in
>> >> > a single call)."
>> >>
>> >> Yeah, ok.
>> >>
>> >> >> But I think this whole "moving target" label is really because of the
>> >> >> nature of the generalizations we seem to be talking about.
>> >> >
>> >> > That seems to be a poor excuse. You could have included a formal
>> >> > characterization of FC, FB and (now) FC in relation to F to clarify
>> your
>> >> > "claim"; unless, of course, that characterization is also fuzzy in
>> your
>> >> > mind.
>> >>
>> >> If F is a monadic verb which has a [meaningful] tail recursive
>> >> optimization, FC@(FB^:FT^:_) is sufficient to represent F (and
>> >> typically FC would be the identify function). If F is something else,
>> >> I guess I would have to do something else, also.
>> >>
>> >> >> Also, ... you seem to be abandoning your previous "tail recursive"
>> >> >> functions, rather than showing that they did anything. Was this your
>> >> >> intent? Or are we coming back to them?
>> >> >
>> >> > Am I abandoning them? I seems you cannot grasp what the verb evolve
>> does
>> >> > despite the description of the task in the Rosetta Code site and
>> >> > implementations in dozens of languages, including one in J. I am
>> sorry,
>> >> I
>> >> > cannot help you there; however, certain author of a revision [0]
>> might be
>> >> > able to explain it to you, find "If you are getting lost" in [1]. ;)
>> I
>> >> > wonder why you apparently do not understand what the verb onemore is
>> >> doing
>> >> > either. :D
>> >>
>> >> Eh... the rosettacode evolve
>> >>
>> >> https://rosettacode.org/wiki/Evolutionary_algorithm#J
>> >>
>> >> is considerably different from the evolve you referenced earlier in this
>> >> thread
>> >>
>> >> http://www.jsoftware.com/pipermail/programming/2009-December
>> /017529.html
>> >>
>> >> Not only in structure, but in behavior.
>> >>
>> >> Though, reviewing this thread, I do now notice that you referred to
>> >> the rosettacode instance a few messages back.
>> >>
>> >> Also, the rosettacode implementation of evolve already uses induction...
>> >>
>> >> But, anyways, that's enough hints for me to get going.
>> >>
>> >> The tail recursive routine in the evolve you referenced was recur, and
>> >> the FB^:FT^:_ form of recur would be:
>> >>
>> >> recur=: next^:NotMatch^:_
>> >>
>> >> I hope this helps,
>> >>
>> >> --
>> >> 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
>> ----------------------------------------------------------------------
>> 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
