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
