I wrote:
> You are allowed to show "sneaky" cases where the domain of a verb
> involving (Ca f p g) is reduced because its execution breaks down
> reporting a domain error whereas the corresponding verb involving (Ca
> f p g) produces a result, when both are given the same arguments.
and
> I vaguely remember that initially (@:) was used (and (13 :) had a
> different code?). Perhaps you could try to find out if my
I should have written respectively:
> You are allowed to show "sneaky" cases where the domain of a verb
> involving (Ca f p g) is reduced because its execution breaks down
> reporting a domain error whereas the corresponding verb involving
> ([: f p g) produces a result, when both are given the same arguments.
and
> I vaguely remember that initially (@:) was used (and (13 :) had a
> different number code?). Perhaps you could try to find out if my
On Sat, Dec 8, 2012 at 11:30 AM, Jose Mario Quintana
<jose.mario.quint...@gmail.com> wrote:
> Dan,
>
>> Let me put it a different way: must I find a combination of f g x y such
>> that ( (Ca f p g) y ) -: ( ([: f g) y ) or ( x (Ca f p g) y ) -: ( x
>> ([: f g) y ) does not result in a 1? Or am I allowed sneakier tactics? An
>> example of the kind of sneaky tactic I'm considering is given in the
>> postscript (after some spaces to hide the spoilers).
>
> You are allowed to show "sneaky" cases where the domain of a verb
> involving (Ca f p g) is reduced because its execution breaks down
> reporting a domain error whereas the corresponding verb involving (Ca
> f p g) produces a result, when both are given the same arguments.
> Thus, replacing literally ([: f g), within a sentence, by (Ca f p g)
> does not work in these cases because the new version fails to produce
> a result.
>
>> whether "favoring" requires that the interpreter generate code involving @
>> (instead of [: ) of arbitrary complexity
>
> Yes, and your question is related to the bonus puzzle.
>
>> PS: I noticed your original "(This is a tricky puzzle thought)", and felt
>> it was hinting at something, but haven't grasped what.
>
> You already passed that hurdle by not following the red herring (13 :).
>
>>
>> **SPOILERS BELOW HERE**
>
>
>
>
>
>
>
>
>
>> +/&.([: #: +:) 1 2 3
>> 6
>>
>> +/&.(Ca #:p +:) 1 2 3
>> |domain error
>> | +/&.(Ca#:p+:)1 2 3
>
> Yes, that is definitely the kind of instance that the elimination of
> ([:) requires a little more effort ; well done!
>
>
> Since,
>
> ([: (2&#.)(2&#.)) b. _1
> [: ($&2@>:@(2&(<.@^.))@(1&>.)@(>./)@:|@, #: ]) :.(2&#.)
> ($&2@>:@(2&(<.@^.))@(1&>.)@(>./)@:|@, #: ]) :.(2&#.)
>
> and so on, one can force the interpreter to generate code of arbitrary
> complexity (although built from a finite number of hand-rolled
> inverses). However, this not completely satisfying, because, unlike
> (13 :), (v b. _1) is generating a string representing code as opposed
> to generating a verb (and on top a ([:) shows up).
>
>> the machine J, which automatically generates the [:s from 13 : . Though
>> perhaps there are ways to induce the interpreter to use @ instead of [: when
>> (automatically) generating inverses of compound verbs. Hmm....
>>
>
> I do not know about that. By the way, did Ken and Roger decided to
> favor ([:) over (@:) when generating verbs via (13 :) or just Roger?
> I vaguely remember that initially (@:) was used (and (13 :) had a
> different code?). Perhaps you could try to find out if my
> recollection is correct using very early versions of the J interpreter
> in your collection.
>
>> Anyway, are these solutions on the right tracks?
>
> Perhaps I am too picky regarding the last solution and you should be
> declared a winner and have a look at the bonus puzzle. At the very
> least you are red hot.
>
>
>
> _________________________________________________________________________
>
>
> On Fri, Dec 7, 2012 at 10:08 PM, Dan Bron <j...@bron.us> wrote:
>> Pepe,
>>
>> The specification for the first puzzle is still a bit ambiguous, because:
>>
>>> the equivalence fails because the execution of
>>> sentences involving (Ca f p g) break down when
>>> applied to (meaningful) identical arguments
>>
>> Can apply equally to the cases I was trying to distinguish:
>>
>> (1) a difference .. in the /output/ of these two verbs when applied
>> to identical arguments
>> (2) show differences in products /derived/ from these two
>> ("identical") verbs
>>
>> Both cases are "sentences involving (the constructs in question)" and both
>> involve application to "(meaningful) identical arguments". In the latter
>> case, the "(meaningful) identical arguments" are, in fact, the constructs in
>> question.
>>
>> Let me put it a different way: must I find a combination of f g x y such
>> that ( (Ca f p g) y ) -: ( ([: f g) y ) or ( x (Ca f p g) y ) -: ( x
>> ([: f g) y ) does not result in a 1? Or am I allowed sneakier tactics? An
>> example of the kind of sneaky tactic I'm considering is given in the
>> postscript (after some spaces to hide the spoilers).
>>
>> I've also given a potential solution to the second puzzle, depending on the
>> definition of "the interpreter" or how it "favors" things. In particular,
>> whether "favoring" requires that the interpreter generate code involving @
>> (instead of [: ) of arbitrary complexity, or whether simply producing a @
>> (instead of [:) without my asking for it suffices (meaning, the number of
>> cases I can provoke is finite).
>>
>> For euphony, I've made this first pair of solutions "rhyme".
>>
>> -Dan
>>
>> PS: I noticed your original "(This is a tricky puzzle thought)", and felt
>> it was hinting at something, but haven't grasped what.
>>
>> **SPOILERS BELOW HERE**
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> With Ca =. [ and p =. @] is (Ca #:p +:) "identical" to ([: #: +:) ?
>>
>> ([: #: +:) b. _1
>> [: -: #.
>>
>> (Ca #:p +:) b. _1
>> |domain error
>> | (Ca#:p+:)b._1
>>
>>
>> +/&.([: #: +:) 1 2 3
>> 6
>>
>> +/&.(Ca #:p +:) 1 2 3
>> |domain error
>> | +/&.(Ca#:p+:)1 2 3
>>
>>
>>
>> Does the interpreter ever favor @ or @: over [: ?
>>
>> 2&#. b. _1
>> ($&2@>:@(2&(<.@^.))@(1&>.)@(>./)@:|@, #: ]) :.(2&#.)
>>
>> '@ @: [:' e.&;: 2&#. b. _1
>> 1 1 0
>>
>> +/"1 '@ @: [:' =/&;: 2&#. b. _1
>> 6 1 0
>>
>> Using this approach, I am inclined to take up Henry's usage and name the
>> interpreter "Roger", because it feels more to me like these results convey
>> the preferences of the man Roger, who hand-rolled particular inverses, than
>> the machine J, which automatically generates the [:s from 13 : . Though
>> perhaps there are ways to induce the interpreter to use @ instead of [: when
>> (automatically) generating inverses of compound verbs. Hmm....
>>
>> Anyway, are these solutions on the right tracks?
>>
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
