About
foo=: 3 : '*/p^<.y^.~p=.p:i._1 p:y'
Because _1 p: y gives # primes less than y, one should use:
foo=: 3 : '*/p^<.y^.~p=.p:i._1 p:y+1'
((*./\)-:foo&>) 1+i.23
1
A.G
On 12-03-19 12:59, R.E. Boss wrote:
You don't really need extended precision (for a while), which makes it
obviously a
Yeah, you're right, that was much too hasty.
Thanks.
R.E. Boss
> -Oorspronkelijk bericht-
> Van: Programming
> Namens David Lambert
> Verzonden: dinsdag 12 maart 2019 15:32
> Aan: programming
> Onderwerp: Re: [Jprogramming] LCM performance
>
> That these match proves nothing. Look a
Dear list,
I tried to use the dissect functionality to understand the way how
sentences are processed. On windows I see that while, originally, the
highlighting of parts of the sentence (the pink/violet rectangles) is
ok, when I resize the dissect window, the rectangles appear at wrong
places.
T
That these match proves nothing. Look at the values.
foo=: 3 : '*/p^<.y^.~p=.p:i._1 p:y'
10(-:&foo)10x
1
A=:foo 10
B=:foo 10x
A
_
B
695283836241707197000307586526418388339874291768035113536027537561504144217502123750625798682860204776361287769787645489273366008
You don't really need extended precision (for a while), which makes it
obviously a lot faster.
foo=: 3 : '*/p^<.y^.~p=.p:i._1 p:y'
10(-:&foo)10x
1
R.E. Boss
> -Oorspronkelijk bericht-
> Van: Programming
> Namens Don Guinn
> Verzonden: maandag 11 maart 2019 17:38
> Aan:
Presumably it's the usual trade-off between whole array programming and
the loopy approach.
It must* be worth truncating the logarithm when in a loop, or indeed,
doing two consecutive loops,
from 2 to ~ sqrt n, and then from > ~ sqrt n to n; less useful when
working on the whole array.
*Having
