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: Programming forum
Onderwerp: Re: [J
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 thes
4
Library: 8.06.09
Platform: Win 64
Installer: J806 install
InstallPath: c:/program files/j64-806
Contact: www.jsoftware.com
> From: "R.E. Boss"
> To: "programm...@jsoftware.com"
> Subject: Re: [Jprogramming] LCM performance
> Message-ID:
> &
maandag 11 maart 2019 17:38
> Aan: Programming forum
> Onderwerp: Re: [Jprogramming] LCM performance
>
> 6!:2 'n=:*/p^<.y^.~p=.p:i._1 p:y=.10x'
>
> 0.690272
>
> 40{.":n
>
> 6952838362417071970003075865264183883398
>
> On Mon,
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
t
> > >>>>>> faster:
> > >>>>>>
> > >>>>>> lcmseq=:3 :0
> > >>>>>> primes=. i.&.(p:inv) y
> > >>>>>> maxsq=. 1+primes I.%:y
> > >>>>>> */primes^x:1>.
gt;>> lcmseq=:3 :0
> >>>>>> primes=. i.&.(p:inv) y
> >>>>>> maxsq=. 1+primes I.%:y
> >>>>>> */primes^x:1>.(#primes){.<.(maxsq{.primes)^.y
> >>>>>> )
> >>>>>>
> >>>
10x
>>>>>>
>>>>>> 6952838362417071970003075865264183883398742917680351135360275375615041442175021237506257986828602047763612877697876454892733660081058707575359683162985199273472095475166897891861381578830560627099383483382709560516260628624180504874681127372
7763612877697876454892733660081058707575359683162985199273472095475166897891861381578830560627099383483382709560516260628624180504874681127372319705939469099...
>>>> >6!:2'lcmseq 10x'
>>>> > 0.398073
>>>> >
>>>> > I hope this helps,
>>>> >
>&g
348338270956051626062862418050487468112737
>>> 2319705939469099...
>>> >6!:2'lcmseq 10x'
>>> > 0.398073
>>> >
>>> > I hope this helps,
>>> >
>>> > --
>>> > Raul
>>> >
>>
> >
>> > > That, I suspect, can be blamed mostly on the abysmally slow extended
>> > precision integers in J, and the fact that *. must manipulate these
>> > extended precision integers more often than other verbs.
>> > >
>> > > Indeed, If you
suspect, can be blamed mostly on the abysmally slow extended
> > precision integers in J, and the fact that *. must manipulate these
> > extended precision integers more often than other verbs.
> > >
> > > Indeed, If you remove the 'x', it runs extremely
Indeed, If you remove the 'x', it runs extremely fast.
From: Programming on behalf
of Eugene Nonko
Sent: Sunday, March 10, 2019 9:00 PM
To: programm...@jsoftware.com
Subject: [Jprogramming] LCM performance
I need to find the smallest number that d
extended precision integers more often than other verbs.
Indeed, If you remove the 'x', it runs extremely fast.
From: Programming on behalf
of Eugene Nonko
Sent: Sunday, March 10, 2019 9:00 PM
To: programm...@jsoftware.com
Subject: [Jprogramming] LCM perform
in J, and the fact that *. must manipulate these
> extended precision integers more often than other verbs.
> >
> > Indeed, If you remove the 'x', it runs extremely fast.
> > ____
> > From: Programming on behalf
> of Eugene Nonko
> > S
Haskell does not have any clever way to short-circuit evaluation of LCM for
arbitrary precision Integer type.
LCM is defined as follows:
lcm _ 0 = 0
lcm 0 _ = 0
lcm x y = abs ((x `quot` (gcd x y)) * y)
And GCD is implemented straightforwardly using Euclid algorithm:
g
On Sunday, March 10, 2019, james faure wrote:
> For reference, the haskell implementation doesn't have any special magic
> to it, besides the lazy list handling:
I was suggesting that the Haskell compiler might have enough number theory
implemented to discard the irrelevant duplicate factors fr
I googled, Haskell used the GMP library for extended integer.
On Mon, Mar 11, 2019, 4:00 AM Eugene Nonko wrote:
> I need to find the smallest number that divides all numbers from 1 to n.
> The solution, of course is this:
>
> *./ >: i. n
>
> What I don't understand is why this solution seems to
= 0
lcm x y = abs ((x `quot` (gcd x y)) * y)
From: Programming on behalf of james
faure
Sent: Sunday, March 10, 2019 11:42 PM
To: programm...@jsoftware.com
Subject: Re: [Jprogramming] LCM performance
For reference, the haskell implementation doesn't ha
kage/base-4.12.0.0/docs/src/GHC.Num.html#%2A>
y<http://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.Real.html#local-6989586621679043781>)
From: Programming on behalf of Raul
Miller
Sent: Sunday, March 10, 2019 10:38 PM
To: Programming forum
Su
P.S. the english describing this problem here should be fixed.
The smallest positive number which divides 1+i.n evenly is 1 and a 1:
would be a verb to compute that value.
The number being computed here is the smallest positive number which
1+i.n divides (with an integer result).
(If we allowed
> Indeed, If you remove the 'x', it runs extremely fast.
>
> From: Programming on behalf of
> Eugene Nonko
> Sent: Sunday, March 10, 2019 9:00 PM
> To: programm...@jsoftware.com
> Subject: [Jprogramming] LCM performance
>
> I need to find
_
From: Programming on behalf of
Eugene Nonko
Sent: Sunday, March 10, 2019 9:00 PM
To: programm...@jsoftware.com
Subject: [Jprogramming] LCM performance
I need to find the smallest number that divides all numbers from 1 to n.
The solution, of course is this:
*./ >: i. n
What I don't unde
I need to find the smallest number that divides all numbers from 1 to n.
The solution, of course is this:
*./ >: i. n
What I don't understand is why this solution seems to scale so poorly:
6!:2 '*./ >: i.1x'
0.326128
6!:2 '*./ >: i.11000x'
1.00384
6!:2 '*./ >: i.12000x'
4.133
6!:
24 matches
Mail list logo
