See also Roger's essay:
https://code.jsoftware.com/wiki/Essays/Chudnovsky_Algorithm
On Tue, Dec 22, 2020 at 3:22 PM Hauke Rehr <hauke.r...@uni-jena.de> wrote:
>
> a worthy read, thanks
>
> I think I fell in love with J in part
> due to its notationally pleasant guise
> There are so many debates in notation.
> I personally prefer τ over π but I’m
> okay with o.1 and 1p1 meaning πª
> (I’d like to have 1t1 at my disposal);
> and I’m unsure about the Triangle of Power
> but I think it’s worth considering,
> at least in education;
> etc. etc.
>
> As for parethesesº, I’m amoung those trying to avoid paren-noise as much
> as possible (in tex, for example, I build mostly commands taking single
> letters, symbols or commands as input so I may omit braces – but I agree
> this can render texts unreadable if applied excessively).
>
> This personal taste notwithstanding, I do appreciate your
> aesthetics-based plea for expressions like (x>0)-(x<0),
> but I’d rather say x (> - <) 0 instead. (DRY principle)
>
> And I forgot to mention I also think 3. is another important argument.
> When I taught J to pupils recently, they were overwhelmed by the way
> this actually is more readable and intuitive, e. g.
> append =: ,
> product_of_items =: */
> append_its_product =: append product_of_items
> when I had been talking about forks.
>
>
> ª now we’re back with this thread’s topic – in some way
> º in German, “Klammern” are any of ()[]{}
>
>
> Am 22.12.20 um 22:00 schrieb Roger Hui:
> > 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 <hauke.r...@uni-jena.de> 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 <rogerhui.can...@gmail.com>
> >>> 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 <devon...@gmail.com>
> >>>> 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
> >
>
> --
> ----------------------
> 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
