⚠️ Warning: This is a draft ⚠️

This means it might contain formatting issues, incorrect code, conceptual problems, or other severe issues.

If you want to help to improve and eventually enable this page, please fork RosettaGit's repository and open a merge request on GitHub.

== forward difference of one number ==

It is very nice to see the [[Python]] entry. Studying it has improved my grasp of that language. --[[User:TBH|TBH]] 09:45, 11 January 2008 (MST)

== J: verb vs adverb ==

With regard to the replacement of '''((}. - }:) ^:)''' by '''(2&(-/))''': I agree that a solution in the form of a verb is somewhat better than a solution that is an adverb, although the benefits strike me as subtle and minor. I think the original solution is worth retaining as an example because of its form. It is not only a different algorithm, it is another strong example of how tacit form allows one to "code the concept." These two solutions complement one another, so both should be included. Contrary to the comment upon replacement, the new program is not shorter than the first solution. This is demonstrated by the following J interaction: #;:'(}. - }:) ^:' 6 #;:'2&(-/)' 7 --[[User:TBH|TBH]] 21:13, 20 August 2008 (UTC)

:Yep, both solutions could be retained. I'll put the orig back in a moment. To address your specific comments:

:I actually think that 2 -/\ y is a clearer expression of the concept of forward differences. That is, I think of a forward difference as "inserting a - between each pair of numbers", which is exactly what 2 -/\ y tells J to do; it took me a moment to realize subtracting the curtail from the behead is equivalent.

:Of course, this is entirely subjective: it depends on the way you think about the problem. So you may think of "forward differences" exactly as "subtracting the behead from the curtail". In fact, I think some of the other languages calculate their results exactly that way, so the original solution may serve better as a "direct translation".

:Regarding verbal vs adverbal: I don't think the differences are minor (though they may be subtle). The primary argument for a verb solution runs like this: we have two noun inputs and want to produce a noun output, which is the very definition of a dyadic verb. All the arguments are supplied at "run time" not "definition time", and no new verbs are produced, so the adverb does not benefit us. Yet it costs us plenty: adverbs are hard to use like verbs. For example, how would you write the equivalent of +/@(2&(-/)) (the sum of the forward differences) without rewriting your the adverb as a verb? You'd have to go through convolutions like ((}.-}:)^:)(+/@).

:A secondary (but still important) difference is generality: Verbal solutions can be easily extended with rank, but it's difficult to slice-and-dice arguments to adverbs. For example, how would you recreate this result using the adverb solution? (3 2 3) 2&(-/)"_1 ?. 3 5 \$ 10 16 _20 0 16 _14 11 _17 22 0

:Or even this (however contrived)? (-:@#`],:<@#`+:) 2&(-/)"1 ] 16 7 82 4 NB. Apply different verbs (i.e. a multidim array of verbs is an argument) 84 _153 0 0 0 0 0 0 0 0 0 0 0 0 0 0

32 14 164 8 18 _150 156 0 168 _306 0 0 474 0 0 0

:You're right that the adverb is a concise expression of the concept, which emphasizes J's strengths. I find the verb solution another compelling example of that: 2&(-/) is how you would code the simple forward difference (i.e. as a monad). The fact that it works as a dyad to produce the Nth forward difference (without a single change) highlights J's value as a notation. Put another way, I find it pleasant that monad is the dyad with an implicit left argument of 1, which is the "normal use case".

:Finally, With regard to length, my metric was # rather than #@;:, as in : #'(}.-}:)^:' 9 #'2&(-/)' 7

:I chose # because the comment on the solution specifically highlighted succinctness, and total length is the metric of succictness for the solution's target audience (i.e. developers unfamiliar with J, who we're trying to impress).

[[User:DanBron|DanBron]] 23:01, 26 August 2008 (UTC) ::Thank you for elaborating on why it is beneficial to code this as a verb, rather than as an adverb. It is always nice to get explanation for a correction. ::As for which algorithm is a more "natural" or elegant expression, it seems like one of those tough calls. I'm sure my bias was merely a function of what I happened to learn first. Over time I may well come to prefer the version that relies on Infix. I do now concede that is is significantly better because it produces a verb. --[[User:TBH|TBH]] 19:07, 27 August 2008 (UTC)