May I suggest that you read Conventions Governing Order of Evaluation <https://www.jsoftware.com/papers/EvalOrder.htm> [Iverson 1966].
On Tue, Dec 22, 2020 at 12:46 PM Hauke Rehr <[email protected]> wrote: > IMO the value of right-to-left data flow is > that it reflects the way math notation works. > operatorD operatorC operatorB operatorA data > is “evaluated” from right to left. > -/ I used to consider merely a convenience. > Having read Roger’s answers, I guess I might > have been wrong. > > !warning: opinions/ranting ahead! > Anyone objecting against this doesn’t know > or doesn’t like maths. > Sadly, even methematicians often don’t know > their grammar, writing incomprehensible nonsense > like (ℚ is dense in ℝ) > ∃q∈ℚ: d(q,r)<ε ∀r∈ℝ, ε>0 > instead of (my preferred way) > ∀(r,R)∈ℝ²∩<: ∃q∈ℚ: ((r,q),(q,R))∈<² > One might argue for “r<q<R” to be an okay alternative > for the part after the last colon. I’d disagree still. > What would “true<R” or “r<false” mean? > > Am 22.12.20 um 19:44 schrieb Devon McCormick: > > Thanks everyone for the tips! > > > > Bob - your suggestions still stalls: > > 20j18":%12x*-/chudSeriesa i.2 > > 3.141592653589788641 > > 20j18":%12x*-/chudSeriesa i.3 > > 3.141592653589788641 > > (Should be > > 3.14159265358979323846... > > as we all know :) ) > > > > Roger's suggestion will take me longer to translate. > > > > I got into this diversion from thinking about the array languages FAQ I > > mentioned in the KEI Centenary discussion last Thursday. One of the > first > > objections a lot of people have is the right-to-left order of evaluation > > and I wanted a good illustration of how this gives you alternating sum > with > > -/ . I found it discouraging to read a recent missive from Niklaus > Wirth > > where he takes a jab at this useful simplification as an example of an > > unwarranted complication. It's sad that an eminent luminary like this > has > > failed to grasp, after all these years, how useful this convention is. > > > > The Chudnovsky formula is a good illustration because it includes a > "_1^k" > > term to force the alternating sum. > > > > > > > > > > On Tue, Dec 22, 2020 at 12:56 PM Roger Hui <[email protected]> > > wrote: > > > >> In the J source, file vx.c, function jtxpi(), you find an > implementation of > >> the Chudnovsky algorithm using extended precision arithmetic. It is in > C > >> but it should not be too hard to figure out the J equivalent. > >> > >> static XF1(jtxpi){A e;B p;I i,n,n1,sk;X a,b,c,d,*ev,k,f,m,q,s,s0,t; > >> RZ(w); > >> if(!XDIG(w))R xzero; > >> ASSERT(jt->xmode!=XMEXACT,EVDOMAIN); > >> RZ(a=xc(545140134L)); > >> RZ(b=XCUBE(xc(640320L))); > >> RZ(c=xc(13591409L)); > >> RZ(d=xplus(xc(541681608L),xtymes(xc(10L),xc(600000000L)))); > >> n1=(13+AN(w)*XBASEN)/14; n=1+n1; > >> RZ(e=piev(n,b)); ev=XAV(e); m=ev[n1]; > >> f=xzero; s0=xone; sk=1; > >> for(i=p=0;;++i,p=!p){ > >> s=xtymes(s0,xplus(c,xtymes(a,xc(i)))); > >> t=xdiv(xtymes(s,m),ev[i],XMEXACT); > >> f=p?xminus(f,t):xplus(f,t); > >> if(i==n1)break; > >> DO(6, s0=xtymes(s0,xc(sk++));); RE(s0); /* s0 = ! 6*i */ > >> } > >> f=xtymes(d,f); > >> q=xpow(xc(10L),xc(14*n1)); > >> k=xtymes(xtymes(a,m),xsqrt(xtymes(b,xsq(q)))); > >> R xdiv(xtymes(k,w),xtymes(f,q),jt->xmode); > >> } /* Chudnovsky Bros. */ > >> > >> > >> On Tue, Dec 22, 2020 at 9:30 AM Devon McCormick <[email protected]> > >> wrote: > >> > >>> The Chudnovsky algorithm - > >>> https://en.wikipedia.org/wiki/Chudnovsky_algorithm - is supposed to > have > >>> the fastest convergence for pi (or 1/pi, to be exact). I had tried > this > >>> one which is OK but only seems to add one digit for each power of 10: > >>> 6!:2 'pi=. 4*-/%>:+:i. 1e6' > >>> 0.0145579 > >>> 20j18":pi > >>> 3.141591653589793420 > >>> 6!:2 'pi=. 4*-/%>:+:i. 1e7' > >>> 0.140673 > >>> 20j18":pi > >>> 3.141592553589793280 > >>> 6!:2 'pi=. 4*-/%>:+:i. 1e8' > >>> 1.44487 > >>> 20j18":pi > >>> 3.141592643589793177 > >>> 6!:2 'pi=. 4*-/%>:+:i. 1e9' > >>> 16.7988 > >>> 20j18":pi > >>> 3.141592652589793477 > >>> > >>> The Chudnovsky series is fast and gives me 15 correct decimal digits > for > >>> only 2 iterations but fails to improve after that presumably because of > >>> floating point limitations: > >>> 20j18":%12*-/chudSeries i.2 > >>> 3.141592653589795336 > >>> 20j18":%12*-/chudSeries i.3 > >>> 3.141592653589795336 > >>> 20j18":%12*-/chudSeries i.4 > >>> 3.141592653589795336 > >>> chudSeries i.4 > >>> 0.0265258 4.98422e_16 2.59929e_30 1.45271e_44 > >>> > >>> However, when I try to use extended precision, it does not seem to give > >> me > >>> extended precision results: > >>> chudSeries=: 13 : '((!6x*x: y)*13591409x+545140134x*x: y)%(!3x*x: > >>> y)*(3x^~!x: y)*640320x^3r2+3x*x: y' > >>> > >>> I get the same fp values for the "i.4" argument as shown above. Am I > >> doing > >>> something wrong or overlooking something? > >>> > >>> Thanks, > >>> > >>> Devon > >>> > >>> -- > >>> > >>> Devon McCormick, CFA > >>> > >>> Quantitative Consultant > >>> ---------------------------------------------------------------------- > >>> For information about J forums see http://www.jsoftware.com/forums.htm > >>> > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > >> > > > > > > -- > ---------------------- > mail written using NEO > neo-layout.org > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
