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
