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
