I think your approach was fine. Integer arithmetic, after all, has a recursive definition. (Which, thankfully, we mostly just assume exists rather than using as a technique to slow things down.) https://en.wikipedia.org/wiki/Peano_axioms
Thanks, -- Raul On Sat, Sep 30, 2017 at 8:59 AM, Don Guinn <[email protected]> wrote: > I didn't realize that the solution was supposed to be recursive. I got > tired of trying to figure out recursive or polynomial solutions for a > series of numbers in Project Euler and found it easy to use matrix division > when there is a polynomial solution. > And given a polynomial solution for each term it is possible to do reverse > difference calculus to come up with the polynomial for the sum of the > series as many times they want millions of terms added for a solution. Of > course, with J it's no problem to sum millions of terms, but it's fun > figuring out how to avoid that. > > I kind of feel like it's cheating as I know what they are trying to get us > to do. But isn't that what math is all about? Finding simpler ways to solve > a problem? > > > On Sat, Sep 30, 2017 at 5:13 AM, bill lam <[email protected]> wrote: > >> Since the time taking is small, better to run n times >> to obtain an average. >> >> + and - are scalar functions of rank-0, but J has >> integrated rank support so that there will be no >> performance penalty if its arguments are arrays. >> >> @ will inherent the rank of - , better to use @: in >> this case. >> >> 50 ts'(3 :''-y'')@- v' >> 0.183617 8.39565e6 >> 50 ts't@- v' >> 0.105698 8.3904e6 >> >> 50 ts'(3 :''-y'')@:- v' >> 0.00245378 1.67837e7 >> 50 ts't@:- v' >> 0.00206336 8.39002e6 >> >> IMO it doesn't matter whether to use tacit or explicit, >> the more important thing is to understand how J works. >> >> >> Сб, 30 сен 2017, Erling Hellenäs написал(а): >> > Hi all ! >> > >> > Can tacit and explicit J be interchangeably used everywhere ? >> > >> > Examples of use: >> > >> > 4 (3 :'- y')@:(4 :'x + y') 5 >> > _9 >> > 3(4 :'(1: x + y)#''x'' ')`(4 :'(1: x + y)#''y'' ')@.(4 :'x < y')4 >> > y >> > >> > What are the performance implications of using explicit J instead of >> tacit >> > J? >> > >> > This little example indicates that tacit J is about twice as fast? >> > >> > v=.?~1000000 >> > 10{.v >> > 733026 963097 739111 754321 510732 704647 209066 833891 281909 851842 >> > #v >> > 1000000 >> > t=: - >> > e=: 3 :'-y' >> > ts't@- v' >> > 0.49503 2.6439e8 >> > ts'e@- v' >> > 0.743922 2.6439e8 >> > ts'(3 :''-y'')@- v' >> > 0.38011 2.64395e8 >> > ts'(-)@- v' >> > 0.186993 2.6439e8 >> > ts'-@- v' >> > 0.182542 2.6439e8 >> > ts'(3 :''- <: >: y'')@- v' >> > 0.465578 2.64395e8 >> > ts'([: - [: <: [: >: ])@- v' >> > 0.25002 2.64391e8 >> > *./ (t@- v) = v >> > 1 >> > *./ (e@- v) = v >> > 1 >> > *./ ((3 :'-y')@- v) = v >> > 1 >> > *./ ((-)@- v) = v >> > 1 >> > *./ (-@- v) = v >> > 1 >> > *./ ((3 :'- <: >: y')@- v) = v >> > 1 >> > *./ (([: - [: <: [: >: ])@- v) = v >> > 1 >> > >> > Cheers, >> > >> > Erling >> > >> > >> > >> > On 2017-09-29 20:10, Erling Hellenäs wrote: >> > > An additional comment. see below. /Erling >> > > >> > > On 2017-09-29 04:45, Henry Rich wrote: >> > > > Taking your last sentence first, you would have to supply some >> > > > evidence to make me believe that tacit forms have any intrinsic >> > > > performance penalty. >> > > > >> > > > It is dawning on me that you want fast function definition, but that >> > > > you want it to produce tacit code. You find the current tacit >> > > > language difficult, and you propose to replace it with something >> > > > that looks more like the explicit language. That seems like a >> > > > mistake to me, because: >> > > > >> > > > 1. Most of the responders on this Forum don't agree with you that >> > > > the tacit language is opaque >> > > > >> > > > 2. Even with a fast function definition, many J programmers (I dare >> > > > not say all J programmers with a soul) will always prefer (+ i.) to >> > > > (. x + i. y). >> > > This is a strange comparison, (+ i.) is comparable to + i. with >> explicit >> > > syntax. [ ( + i. ) ] is comparable to x + i. y and ([ (+ i.) ]) is >> > > comparable to (. x + i. y). >> > > > >> > > > 3. Tacit code is a different mindset from explicit code. It's >> > > > functional. It doesn't have assignments or control words >> > > > >> > > > 4. Operands to modifiers cannot be arguments to tacit code >> > > > >> > > > 5. Explicit syntax is an improvement in some cases, not all. +/ *: >> > > > y is a little lighter than +/@:* y but (+/ y) % #y is heavier than >> > > > (+/ % #) y >> > > > >> > > > 6. So: even if I were redesigning the language from scratch, I >> > > > wouldn't represent tacit forms your way. I would, as Roger has >> > > > observed, switch the meanings of (u v) and (u@:v), but I would keep >> > > > the rest as is. >> > > > >> > > > [Note for those who have not been using J for more than 10 years: >> > > > the original tacit language allowed trains that produced modifiers. >> > > > That was, to me, Ken's finest achievement: a really beautiful >> > > > language, immensely supple, even though it had no syntactic elements >> > > > but the primitives and parentheses. I never found it wanting. It >> > > > was fully understood by no more than half a dozen people, I think. >> > > > It was removed from J because explicit forms could produce the same >> > > > results: a good business decision, but a loss to computer science >> > > > and art.] >> > > > >> > > > 7. The bottom line: tacit forms work pretty well as they are, and an >> > > > incompatible change to them could be justified only by a huge >> > > > improvement in readability or efficiency. You haven't shown that. >> > > > >> > > > Henry Rich >> > > > >> > > > On 9/28/2017 10:09 PM, Erling Hellenäs wrote: >> > > > > Hi all ! >> > > > > >> > > > > Is improving explicit J the way forward? Or is tacit J and >> > > > > improving tacit J the way forward? >> > > > > I also think that "Henry's" proposal, which is similar to what I >> > > > > have been writing about for a long time, is great. It is easy >> > > > > to do and have great benefits for people working in explicit J. >> > > > > They will not have to type lots of double quotes, or write their >> > > > > own J versions with special duplicate quote functionality. >> > > > > That doesn't mean that tacit J could not also be improved? >> > > > > Henry's proposal is nearly identical to my proposal but mine is >> > > > > about tacit J, it is addressing problems with tacit J. His is >> > > > > about explicit J. It is addressing problems with explicit J, the >> > > > > quote duplication problem. I am addressing problems with tacit >> > > > > J, mainly the problem which makes people write cross-compilers >> > > > > from explicit to tacit J or programs to automatically pack verb >> > > > > sequences in tacit J into their packages of brackets and phony >> > > > > "compositors", like this - f@:(g@:(h@:(i@:(j@:])))). People who >> > > > > are working professionally with tacit J and who knows that >> > > > > cheating and writing tacit J like most other people do will slow >> > > > > their programs much too much? >> > > > > >> > > > > Cheers, >> > > > > Erling >> > > > > >> > > > > On 2017-09-29 03:13, Joe Bogner wrote: >> > > > > > I also like Henry's suggestion of fast function definition. It's >> also >> > > > > > unclear to me on how the Erling's suggestion improves upon that. >> > > > > > >> > > > > > On Thu, Sep 28, 2017 at 5:45 PM, Louis de Forcrand >> > > > > > <[email protected]> wrote: >> > > > > > >> > > > > > > I don't really understand what you wish to add either, Erling. >> > > > > > > >> > > > > > > If you want to use explicit J syntax, you could write an >> > > > > > > explicit verb. >> > > > > > > >> > > > > > > You write: >> > > > > > > > Particularly to create what you most commonly need, a >> sequence of >> > > > > > > > monadic verbs, each acting on the result of the verb to the >> right. >> > > > > > > > Well, it is not complicated as such, but for some >> > > > > > > > reason people don't >> > > > > > > like >> > > > > > > > the obvious way to do it, which is [: f [: g [: h ]. >> > > > > > > > Then they dive into >> > > > > > > a >> > > > > > > > mess of complications. I mean the cap should not be >> necessary. That >> > > > > > > simple >> > > > > > > > right to left execution should be the default, >> > > > > > > > possibly modified with >> > > > > > > > parenthesis. That tacit and explicit J should have >> > > > > > > > the same basic syntax. >> > > > > > > f@:g@:h? >> > > > > > > In addition, I disagree with your last two sentences. >> > > > > > > What's the point of >> > > > > > > having tacit syntax if it's the same as explicit syntax? If >> you want >> > > > > > > explicit syntax, write an explicit verb; other times >> > > > > > > tacit syntax is really >> > > > > > > practical. >> > > > > > > In an explicit verb, simple right to left execution *is* the >> default. >> > > > > > > >> > > > > > > In any case I don't really see how the rest of your >> > > > > > > suggestion differs >> > > > > > > from Henry's (.). verbs, which I like very much by the way. >> > > > > > > >> > > > > > > Cheers, >> > > > > > > Louis >> > > > > > > >> > > > > > > > On 28 Sep 2017, at 14:53, Raul Miller <[email protected]> >> wrote: >> > > > > > > > >> > > > > > > > Jose's work is impressive, but I try to avoid it >> > > > > > > > because of the extra >> > > > > > > > complexity it creates when I want to (for example) >> > > > > > > > provide a parameter >> > > > > > > > in clauses for conjunctions like &. -- the extra complexity >> can be a >> > > > > > > > nice mental exercise and maybe even a cure for boredom, but >> I feel >> > > > > > > > that I have the right to treat it as unnecessary. >> > > > > > > > >> > > > > > > > Thanks, >> > > > > > > > >> > > > > > > > -- >> > > > > > > > Raul >> > > > > > > > >> > > > > > > > >> > > > > > > > On Thu, Sep 28, 2017 at 8:33 AM, Erling Hellenäs >> > > > > > > > <[email protected]> wrote: >> > > > > > > > > Hi all ! >> > > > > > > > > >> > > > > > > > > I am very impressed by Jose's work and I think it is an >> excellent >> > > > > > > > > illustration to why we need the modification to J I >> propose. >> > > > > > > > > It is extremely complicated to do these things >> > > > > > > > > which should be simple, >> > > > > > > as I >> > > > > > > > > see it. Particularly to create what you most >> > > > > > > > > commonly need, a sequence >> > > > > > > of >> > > > > > > > > monadic verbs, each acting on the result of the verb to >> the right. >> > > > > > > > > Well, it is not complicated as such, but for >> > > > > > > > > some reason people don't >> > > > > > > like >> > > > > > > > > the obvious way to do it, which is [: f [: g [: h ]. Then >> they dive >> > > > > > > into a >> > > > > > > > > mess of complications. I mean the cap should not be >> necessary. That >> > > > > > > simple >> > > > > > > > > right to left execution should be the default, >> > > > > > > > > possibly modified with >> > > > > > > > > parenthesis. That tacit and explicit J should have the >> same basic >> > > > > > > syntax. I >> > > > > > > > > tried my ideas of a different tacit J in a test >> > > > > > > > > implementation and it >> > > > > > > was >> > > > > > > > > great. >> > > > > > > > > >> > > > > > > > > Cheers, >> > > > > > > > > Erling Hellenäs >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > On 2017-09-28 05:29, Jose Mario Quintana wrote: >> > > > > > > > > > >> > > > > > > > > > Hi Erling, >> > > > > > > > > > >> > > > > > > > > > You are right, the adverb (At) produces tacit sentences >> but it is >> > > > > > > really >> > > > > > > > > > an >> > > > > > > > > > implementation of Dan's pipeline proposal >> > > > > > > > > > using strand notation via a >> > > > > > > > > > Curried adverb (aka, recurrent adverb and multiple >> adverb). >> > > > > > > > > > >> > > > > > > > > > However, I have written (tacitly) a tacit >> > > > > > > > > > Curried adverb (xi) which, >> > > > > > > using >> > > > > > > > > > a lambda-style syntax, produces a tacit verb >> > > > > > > > > > which in turn, given its >> > > > > > > > > > arguments, produces tacit entities. You >> > > > > > > > > > might find xi interesting; the >> > > > > > > > > > general form is, >> > > > > > > > > > >> > > > > > > > > > t=. [: v0 v1 ... vn '...' xi >> > > > > > > > > > >> > > > > > > > > > The names v0 v1 ... vn should be >> > > > > > > > > > syntactically verbs (recall, xi is a >> > > > > > > > > > Curried adverb) but they can represent nouns, verbs, >> adverbs, or >> > > > > > > > > > conjunctions. I use undefined names since those are >> regarded by >> > > > > > > default >> > > > > > > > > > as >> > > > > > > > > > verbs (even if xi does not affect in any way >> > > > > > > > > > the named verbs). The >> > > > > > > > > > literal >> > > > > > > > > > '...' represents a quoted J (or more generally a Jx) >> sentence. >> > > > > > > > > > >> > > > > > > > > > This is how your example can be written using xi, >> > > > > > > > > > >> > > > > > > > > > erase 'b v' >> > > > > > > > > > >> > > > > > > > > > [: v '([: b ''<:b++/\b-~-.b'' xi >> > > > > > > > > > <''\''=v){."0 v' xi <'\\\//\\\//' >> > > > > > > > > > \ >> > > > > > > > > > \ >> > > > > > > > > > \ >> > > > > > > > > > / >> > > > > > > > > > / >> > > > > > > > > > \ >> > > > > > > > > > \ >> > > > > > > > > > \ >> > > > > > > > > > / >> > > > > > > > > > / >> > > > > > > > > > >> > > > > > > > > > There is the nuisance of quotes within >> > > > > > > > > > quotes and the argument must be >> > > > > > > > > > boxed; however, this allows, in general, the verb (t) to >> produce a >> > > > > > > noun, a >> > > > > > > > > > verb, an adverb, or a conjunction and to >> > > > > > > > > > take multiple boxed nouns, >> > > > > > > verbs, >> > > > > > > > > > adverbs, or conjunctions as its argument. >> > > > > > > > > > The following verb (t) acts >> > > > > > > > > > directly on a couple of (boxed) verbs and produces a >> verb, >> > > > > > > > > > >> > > > > > > > > > t=. [: u v 'u/@:v' xi >> > > > > > > > > > >> > > > > > > > > > t[:+*:]: NB. Sum of squares >> > > > > > > > > > +/@:*: >> > > > > > > > > > t[:+*:]: 1 2 3 4 5 >> > > > > > > > > > 55 >> > > > > > > > > > >> > > > > > > > > > t[:-%:]: NB. Difference of square roots >> > > > > > > > > > -/@:%: >> > > > > > > > > > t[:-%:]: 1 2 3 4 5 >> > > > > > > > > > 1.55390522 >> > > > > > > > > > >> > > > > > > > > > Note that the Curried higher-order verb (t) >> > > > > > > > > > is, in effect, acting on >> > > > > > > two >> > > > > > > > > > arguments: [:-%:]: and 1 2 3 4 5; >> > > > > > > > > > furthermore, t [:-%:]: performs a >> > > > > > > > > > partial >> > > > > > > > > > application of the verb (t) acting on [:-%:]: . >> > > > > > > > > > >> > > > > > > > > > The following are variations of the verb >> > > > > > > > > > produced in [0], the verb (t) >> > > > > > > > > > acts on a (boxed) conjunction and produces an adverb, >> > > > > > > > > > >> > > > > > > > > > t=. [: u '(ver adv u)&:train/adv' xi >> > > > > > > > > > >> > > > > > > > > > ]`{.`{:`{: (t [:(<adv@:)]:) NB. Use [:(<'@:')sb in >> J >> > > > > > > > > > ]@:({.@:({:@:{:)) >> > > > > > > > > > >> > > > > > > > > > ]`{.`{:`{: (t [:(<adv@ )]:) NB. Use [:(<'@ ')sb in >> J >> > > > > > > > > > ]@({.@({:@{:)) >> > > > > > > > > > >> > > > > > > > > > ]`{.`{:`{: (t [:(<adv&:)]:) NB. Use [:(<'&:')sb in J >> > > > > > > > > > ]&:({.&:({:&:{:)) >> > > > > > > > > > >> > > > > > > > > > These non-compliant features are not >> > > > > > > > > > provided by the Jx interpreter; >> > > > > > > they >> > > > > > > > > > are, in fact, inherited from the J >> > > > > > > > > > interpreter, the Jx facilities just >> > > > > > > > > > make >> > > > > > > > > > them a lot more accessible. Actually, I have written a >> version >> > > > > > > > > > (admittedly >> > > > > > > > > > cumbersome) of xi in J; see [1] for a link >> > > > > > > > > > to a zip archive and the >> > > > > > > path >> > > > > > > > > > to >> > > > > > > > > > a script where xi is defined. >> > > > > > > > > > >> > > > > > > > > > PS. >> > > > > > > > > > erase'u0 u1 u2' >> > > > > > > > > > 1 1 1 >> > > > > > > > > > [: u0 u1 u2 'u0 + u1 + u2' xi 1 ; 2 ; 3 >> > > > > > > > > > 6 >> > > > > > > > > > >> > > > > > > > > > erase'α β γ' >> > > > > > > > > > 1 1 1 >> > > > > > > > > > [: u0 u1 u2 'u0 + u1 + u2' xi [:α β γ]: >> > > > > > > > > > α + β + γ >> > > > > > > > > > >> > > > > > > > > > References >> > > > > > > > > > >> > > > > > > > > > [0] [Jprogramming] Gerund composed application >> > > > > > > > > > http://www.jsoftware.com/pipermail/programming/2017- >> > > > > > > > > > September/048797.html >> > > > > > > > > > >> > > > > > > > > > [1] J Wicked Toolkit >> > > > > > > > > > http://www.2bestsystems.com/foundation/j/Jx.zip >> > > > > > > > > > \Jx\J\J Wicked Toolkit.ijs >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > On Wed, Sep 27, 2017 at 5:10 AM, Erling Hellenäs >> > > > > > > > > > <[email protected]> >> > > > > > > > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > Hi all ! >> > > > > > > > > > > >> > > > > > > > > > > Pascal, I will come back to your post later. >> > > > > > > > > > > >> > > > > > > > > > > Here is a little compiler written in Jx >> > > > > > > > > > > and compiling, as I understand >> > > > > > > > > > > it, >> > > > > > > > > > > tacit code with explicit J syntax into >> > > > > > > > > > > tacit J. I did not test it, I >> > > > > > > just >> > > > > > > > > > > read the post. >> > > > > > > > > > > http://www.jsoftware.com/pipermail/programming/2017- >> > > > > > > August/048143.html >> > > > > > > > > > > The code snippet Farey is an example of >> > > > > > > > > > > the source code of the little >> > > > > > > > > > > compiler. >> > > > > > > > > > > I just think we should not have to use a tacit J >> compiler from >> > > > > > > explicit J >> > > > > > > > > > > to be able to use explicit J syntax and >> > > > > > > > > > > get a tacit result, a single >> > > > > > > > > > > verb. >> > > > > > > > > > > It would obviously be better to use >> > > > > > > > > > > explicit J syntax in the first >> > > > > > > > > > > place, >> > > > > > > > > > > as i see it. >> > > > > > > > > > > >> > > > > > > > > > > Cheers, >> > > > > > > > > > > >> > > > > > > > > > > Erling >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > ------------------------------ >> ------------------------------ >> > > > > > > ---------- >> > > > > > > > > > > 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 >> > > > > >> > > > > >> > > > > ------------------------------------------------------------ >> ---------- >> > > > > For information about J forums see http://www.jsoftware.com/ >> forums.htm >> > > > >> > > > >> > > > --- >> > > > This email has been checked for viruses by AVG. >> > > > http://www.avg.com >> > > > >> > > > ------------------------------------------------------------ >> ---------- >> > > > 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 >> >> -- >> regards, >> ==================================================== >> GPG key 1024D/4434BAB3 2008-08-24 >> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 >> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 >> ---------------------------------------------------------------------- >> 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
