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
