Oops, I should have said "where next was not a function". But recur was something of a left identity function, when it wasn't throwing errors.
Thanks, -- Raul On Wed, Jan 17, 2018 at 10:34 PM, Raul Miller <[email protected]> wrote: > With all that said, I should point out that > > evolve=:[ > > is a better optimization. > > And, with that in mind, > > FB=: [ > FT=: 1: > > satisfies my original claim for this case. > > This approach does suffer from the conceptual pain of FB being a > function where recur was not a function, but that's just the sort of > sacrifice you have to make when dealing with optimizations. > > Thanks, > > -- > Raul > > > On Wed, Jan 17, 2018 at 9:10 PM, Raul Miller <[email protected]> wrote: >> 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
