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)." > 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. > 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 The kind verbs which could qualify as F seems to be shrinking by the day. So far, we only have seen shifting fuzzy claims waiting for examples and counterexamples. ;) [0] Difference between revisions of "Evolutionary algorithm" http://rosettacode.org/mw/index.php?title=Evolutionary_algorithm&diff=65985&oldid=65977 [1] Talk: Evolutionary algorithm http://rosettacode.org/wiki/Talk:Evolutionary_algorithm#A_Priori_Assumptions.3F On Fri, Jan 12, 2018 at 7:49 PM, Raul Miller <[email protected]> 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). > > But I think this whole "moving target" label is really because of the > nature of the generalizations we seem to be talking about. > > 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? > > It is indeed rather difficult to be "more specific" when we are > talking about general cases. > > Thanks, > > -- > Raul > > > > On Fri, Jan 12, 2018 at 6:36 PM, Jose Mario Quintana > <[email protected]> wrote: > > Well, it turns out that your claim has become a fuzzy moving target: > > > >> So I guess it really should have been (F y) -: (FB^:FT^:_ y) and you > >> might even need a cleanup stage at the end, giving something like (F > >> y) -:FC@:(FB^:FT^:_) y. > > > > First, you might or you might not be including an epilog verb FC in your > > claim. > > > > Indeed, you might need the form FC@:(FB^:FT^:_) depending on whatever > you > > might, or you might not, have in mind for FB and FT when the "task is to > > convert a working tail recursive function" these days. Yet, that epilog > > verb is what I had in mind when I wrote, see below, "almost correct"; > > nevertheless, almost correct ultimately means incorrect and you might, or > > might not, have a counterexample to your original claim. > > > > I wrote, > > > >>> > If I had to guess what you might have in mind for FB and FT in > > connection > >>> > to tail recursion then I would think that the form F=: FB^:FT^:_ > might > > be > >>> > almost correct. However, I rather not guess; I would like to be > > > > Why? Because, the Dictionary's potentially misleading assertion [0] > > notwithstanding, the form u^:v^_ is not a genuine while construction and > in > > some cases it might end prematurely. That is another reason why I > > suggested to look at the verb evolve. > > > > Second, in its latest reincarnation F seems to be required to be a pure > > function; or, you are just guessing that it should be? > > > > Yet, we have had this kind of conversation before at a time when > apparently > > you did not have any issues understanding what the verb evolve is doing > > (although I understand that the passage of time can make a difference) or > > concerns about its (pseudo) random internal components [1]. > > > > The latest (guessed?) restriction seems draconian and Monte Carlo > > algorithms written in a tail recursive form could be now out of bounds. > > > > Moreover, you wrote, > > > >> But, yes, if the task is to convert a working tail recursive function > >> to this form, I am going to have to also insist on example arguments > >> which when handed to that function give a result which shows that the > >> function works for non-identity cases. Otherwise, I'll be spending way > > > > I could have offered one more verb, which might, or might not, had > helped, > > > > inkey=. 1!:1@(1"_) > > > > onemore=. (($:`])@.(3 -: #@:]))@:inkey > > > > onemore'' > > Hello, > > World! > > ! > > ! > > ! > > > > > > Bye > > Bye > > > > > > onemore'' > > 123 > > 123 > > > > However, if F has to be a pure function, inputs from the "outside world" > > (e.g., inputs from the terminal, reading files, querying the time, date, > > etc.) would also now no longer be covered by your current fuzzy claim. > > What appeared to be a potentially interesting claim now might not be so > > much anymore (to me). > > > > You wrote, > > > >> function works for non-identity cases. Otherwise, I'll be spending way > >> more time on irrelevant stuff than I care to. > > > > A friendly advice: When you make a claim and issue a challenge try to > make > > sure that your claim is as clear and as unambiguous as possible and > provide > > illustrating examples; so, your time and perhaps someone else's time is > not > > wasted. (As far as I am concerned, I found this exchange somewhat > > interesting and entertaining up to this point.) ;) > > > > PS. I still have not a clear idea what kind of restrictions are on FB > and > > FT, if any. > > > > [0] Power u^:v > > http://www.jsoftware.com/help/dictionary/d202v.htm > > > > [1] [Jprogramming] Recursive tail calls (WAS: Tacit exercise) > > http://www.jsoftware.com/pipermail/programming/2009- > December/017531.html > > > > > > On Thu, Jan 11, 2018 at 7:26 PM, Raul Miller <[email protected]> > wrote: > > > >> True. Though I had included the y in there to show that I was > >> focusing on the monadic case. > >> > >> So I guess it really should have been (F y) -: (FB^:FT^:_ y) and you > >> might even need a cleanup stage at the end, giving something like (F > >> y) -:FC@:(FB^:FT^:_) y. > >> > >> But, yes, if the task is to convert a working tail recursive function > >> to this form, I am going to have to also insist on example arguments > >> which when handed to that function give a result which shows that the > >> function works for non-identity cases. Otherwise, I'll be spending way > >> more time on irrelevant stuff than I care to. > >> > >> Thanks, > >> > >> -- > >> Raul > >> > >> > >> On Thu, Jan 11, 2018 at 6:18 PM, Jose Mario Quintana > >> <[email protected]> wrote: > >> > Of course, I meant F=: FB^:FT^:_ . By the way, you also meant F=: > >> > FB^:FT^:_, not F=: FB^:FT^:_ y . Did you not? ;) > >> > > >> > Can you think of any verb that cannot be rewritten in that fashion? > >> > > >> > I guess the task description is not clear enough for you; that is > >> > unfortunate. > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > On Thu, Jan 11, 2018 at 6:06 PM, Raul Miller <[email protected]> > >> wrote: > >> > > >> >> On Thu, Jan 11, 2018 at 5:50 PM, Jose Mario Quintana > >> >> <[email protected]> wrote: > >> >> >> Perhaps you could shed a bit more light on whatever it is that you > >> are > >> >> >> trying to talk about? > >> >> > > >> >> > "Because no restrictions on the nature of FB and FT are imposed" my > >> >> > reaction to > >> >> > > >> >> >> 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 > >> >> > >> >> Well, ok, in the sense that either FB or FT could call quicksort. > >> >> > >> >> They still have to represent a tail recursive function for this to be > >> >> meaningful. But even tail recursive routines can call quicksort > >> >> (though, granted, I do not have any clear ideas, right now, about > what > >> >> useful tail recursive routine would call quicksor). > >> >> > >> >> > (so far) is that the part "which satisfies the constraints for tail > >> >> > recursion," is gratuitous. (Can you exhibit a verb F which does > not > >> >> > satisfy the constraints for tail recursion and an F workalike > cannot > >> be > >> >> > written as F=: FB^:^:_ ?) > >> >> > > >> >> > I could be mistaken though and I am willing to be educated. > >> >> > >> >> At this point I don't even know what you are talking about. But I > >> >> think you asked me to rewrite a non-tail recursive routine in a > >> >> syntactically invalid fashion. > >> >> > >> >> Consider, for example: > >> >> > >> >> FB=: 0 >. <: > >> >> FB 2 > >> >> 1 > >> >> FB^:^:_(2) > >> >> |syntax error > >> >> > >> >> > If I had to guess what you might have in mind for FB and FT in > >> connection > >> >> > to tail recursion then I would think that the form F=: FB^:FT^:_ > >> might be > >> >> > almost correct. However, I rather not guess; I would like to be > >> >> enlighted > >> >> > instead, if possible. That is one reason why I suggested the verb > >> >> > evolve as a subject matter. > >> >> > >> >> The only examples I have found for evolve are either: > >> >> > >> >> (a) identity functions (which do nothing whatsoever), or > >> >> (b) throw errors. > >> >> > >> >> How is this relevant? > >> >> > >> >> -- > >> >> 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
