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
